line 2435 column 1 - Warning: trimming empty
#f2dcdc 2393 code active 2007 May anonymous 2007 May 4 4 pragma cache_size not accurate when set to less than 10 It seems that the smallest the cache_size can be is 10 pages, despite what can be set and is reported by the cache_size and default_cache_size pragmas: /* ** Change the maximum number of in-memory pages that are allowed. */ void sqlite3PagerSetCachesize(Pager *pPager, int mxPage){ if( mxPage>10 ){ pPager->mxPage = mxPage; }else{ pPager->mxPage = 10; } } ... static int sqlite3BtreeSetCacheSize(Btree *p, int mxPage){ BtShared *pBt = p->pBt; sqlite3PagerSetCachesize(pBt->pPager, mxPage); return SQLITE_OK; } ... if( sqlite3StrICmp(zLeft,"cache_size")==0 ){ if( sqlite3ReadSchema(pParse) ) goto pragma_out; if( !zRight ){ returnSingleInt(pParse, "cache_size", pDb->pSchema->cache_size); }else{ int size = atoi(zRight); if( size<0 ) size = -size; pDb->pSchema->cache_size = size; sqlite3BtreeSetCacheSize(pDb->pBt, pDb->pSchema->cache_size); ... if( sqlite3StrICmp(zLeft,"default_cache_size")==0 ){ static const VdbeOpList getCacheSize[] = { { OP_ReadCookie, 0, 2, 0}, /* 0 */ { OP_AbsValue, 0, 0, 0}, { OP_Dup, 0, 0, 0}, { OP_Integer, 0, 0, 0}, { OP_Ne, 0, 6, 0}, { OP_Integer, 0, 0, 0}, /* 5 */ { OP_Callback, 1, 0, 0}, }; int addr; if( sqlite3ReadSchema(pParse) ) goto pragma_out; if( !zRight ){ sqlite3VdbeSetNumCols(v, 1); sqlite3VdbeSetColName(v, 0, COLNAME_NAME, "cache_size", P3_STATIC); addr = sqlite3VdbeAddOpList(v, ArraySize(getCacheSize), getCacheSize); sqlite3VdbeChangeP1(v, addr, iDb); sqlite3VdbeChangeP1(v, addr+5, SQLITE_DEFAULT_CACHE_SIZE); }else{ int size = atoi(zRight); if( size<0 ) size = -size; sqlite3BeginWriteOperation(pParse, 0, iDb); sqlite3VdbeAddOp(v, OP_Integer, size, 0); sqlite3VdbeAddOp(v, OP_ReadCookie, iDb, 2); addr = sqlite3VdbeAddOp(v, OP_Integer, 0, 0); sqlite3VdbeAddOp(v, OP_Ge, 0, addr+3); sqlite3VdbeAddOp(v, OP_Negative, 0, 0); sqlite3VdbeAddOp(v, OP_SetCookie, iDb, 2); pDb->pSchema->cache_size = size; sqlite3BtreeSetCacheSize(pDb->pBt, pDb->pSchema->cache_size); The information reported is not accurate: SQLite version 3.3.17 Enter ".help" for instructions sqlite> pragma cache_size; 2000 sqlite> pragma default_cache_size; 2000 sqlite> pragma default_cache_size=3; sqlite> pragma cache_size=7; sqlite> pragma default_cache_size; 3 (should be 10) sqlite> pragma cache_size; 7 (should be 10)
#e8e8bd 2373 new active 2007 May anonymous 2007 May 4 4 "create table as explain " doesn't work When using EXPLAIN to try to figure out why/when indices are being used on some tables and not all sometimes I get a lot of data returned. It would be useful to be able to store this in a table so I can actually use SQL itself to examine the differences in the results I get.
#f2dcdc 2372 code active 2007 May anonymous 2007 May 4 4 sqlite3TestLockingStyle not used if SQLITE_FIXED_LOCKING_STYLE defined static function sqlite3TestLockingStyle() is not used if SQLITE_FIXED_LOCKING_STYLE is defined. It should probably be wrapped in: #ifndef SQLITE_FIXED_LOCKING_STYLE
#e8e8bd 2308 build active 2007 Apr anonymous 2007 Apr 4 3 make sqlite3.c recreates sqlite3.c even though nothing changed When building the amalgamized sqlite3.c source file, make will recreate the sqlite3.c source file each time it's run. When using this as part of a larger build process, this is annoying, since it will result in unnecessary compilations. The fix is to rename the makefile target target_source to tsrc to make sure make will be able to properly detect the dependencies. Below is a patch for Makefile.in that fixes this: --- Makefile.in 19 Apr 2007 10:20:59 -0000 1.167 +++ Makefile.in 19 Apr 2007 11:08:50 -0000 @@ -296,14 +296,14 @@ # files are automatically generated. This target takes care of # all that automatic generation. # -target_source: $(SRC) parse.c opcodes.c keywordhash.h $(VDBEHDR) +tsrc: $(SRC) parse.c opcodes.c keywordhash.h $(VDBEHDR) rm -rf tsrc mkdir -p tsrc cp $(SRC) $(VDBEHDR) tsrc rm tsrc/sqlite.h.in tsrc/parse.y cp parse.c opcodes.c keywordhash.h tsrc -sqlite3.c: target_source $(TOP)/tool/mksqlite3c.tcl +sqlite3.c: tsrc $(TOP)/tool/mksqlite3c.tcl tclsh $(TOP)/tool/mksqlite3c.tcl # Rules to build the LEMON compiler generator _2007-Apr-20 06:01:23 by anonymous:_ {linebreak} Make does not deal well with directories as dependencies (because their last modification time doesn't mean what Make thinks it means). It would be much better to use a stamp file.
#f2dcdc 2310 code active 2007 Apr anonymous 2007 Apr anonymous 4 4 Problem installing on AIX 5.3, ML5 after successful compile with xlc After performing the suggested edits to the Makefile (from Tom Poindexter 2003-12-17): edit Makefile, change the TCC macro: TCC = xlc -q32 -qlonglong -D_LARGE_FILE=1 -D_LARGE_FILES=1 -DUSE_TCL_STUBS=1 -O2 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I${TOP}/src Version 3.3.15 compiled perfectly. However, a make install gave me this: : /data/bld --> make install tclsh ../sqlite-3.3.15/tclinstaller.tcl 3.3 couldn't open ".libs/libtclsqlite3.so": no such file or directory while executing "open $LIBFILE" invoked from within "set in [open $LIBFILE]" (file "../sqlite-3.3.15/tclinstaller.tcl" line 23) make: 1254-004 The error code from the last command is 1. I had to edit line 8 of ../sqlite-3-3-15/tclinstaller.tcl by adding a ".0" to the end. Then it installed perfectly. _2007-Apr-19 20:47:24 by anonymous:_ {linebreak} Haven't used AIX or xLC for 15 years - does IBM still make UNIX machines?
#e8e8bd 2302 build active 2007 Apr anonymous 2007 Apr anonymous 4 4 sqlite3 does not honor configure --disable-threads anymore In a non-threaded TCL build, the TEA configuration option --disable-threads is no longer honored. In version 3.3.12 this used to work: (test) 49 % packa req sqlite3 couldn't load file "/usr/local/tcl/8.5a5-1/lib/sqlite3.3.15/libsqlite3.3.15.so": /usr/local/tcl/8.5a5-1/lib/sqlite3.3.15/libsqlite3.3.15.so: undefined symbol: pthread_create (test) 50 % packa req -exact sqlite3 3.3.12 3.3.12 In new file tclsqlite3.c, line 11734, threading is hard-coded with #define THREADSAFE 1 A workaround for non-threaded builds is to set this manually to #define THREADSAFE 0 _2007-Apr-15 17:03:07 by anonymous:_ {linebreak} I encountered the same problem and I agree that this change is problematic and should be reverted. ---- _2007-Apr-15 18:03:05 by drh:_ {linebreak} Why is it such a problem that the library is threadsafe? Just because it is threadsafe does not mean you are required to use threads, or anything like that. Everything continues to work normally in a single threaded application. There is no measurable performance impact. Why is it so important to you that the threading mutexes not be enabled? ---- _2007-Apr-15 19:34:11 by anonymous:_ {linebreak} In a shared library setting it's not such a big deal, but in a purely static binary it can pull in a fair bit of unwanted thread library code. Also, some embedded UNIX-like targets lack a pthreads implementation. The autoconf default can be threadsafe instead of non-threadsafe. It would be nice if it respected the autoconf flag as it did before.
#f2dcdc 2288 code active 2007 Apr anonymous 2007 Apr 4 2 FTS does not support REPLACE Simple to replicate: CREATE VIRTUAL TABLE fts_table USING fts2(text); INSERT OR REPLACE INTO fts_table (rowid, text) VALUES (1, 'text1'); INSERT OR REPLACE INTO fts_table (rowid, text) VALUES (1, 'text2'); The first insert succeeds, the second fails. Also occurs with fts1. _2007-Apr-10 15:27:10 by anonymous:_ {linebreak} http://www.mail-archive.com/sqlite-users%40sqlite.org/msg23865.html
#e8e8bd 2280 new active 2007 Mar anonymous 2007 Mar 4 3 Check constraint failure message should include field name When an insert or update fails due to a check constraint the error message only says that the insert/update failed. It would be nice if the error message included the field name related to the failed check constraint. Thanks, Sam _2007-Mar-31 00:53:55 by drh:_ {linebreak} Duplicate of ticket #2258
#e8e8bd 1802 build active 2006 May anonymous Unknown 2007 Mar 4 4 sqlite.pc needs -lrt on Solaris for fdatasync() sqlite 3.3.x correctly checks for fdatasync() in -lrt during its configure, so it will make use of fdatasync() on Solaris. The problem is that the sqlite.pc doesn't record that -lrt is needed when other packages wish to link with sqlite, so other packages will fail to link using the Libs: entry from sqlite.pc. I think this could be fixed by just adding @TARGET_LIBS@ to the end of the Libs: line in sqlite.pc.in, since TARGET_LIBS should only contain any necessary additional libraries. The later call to AC_SUBST(TARGET_LIBS) will then handle getting any libraries listed in TARGET_LIBS substituted in. I will submit a patch, if you wish, if you think that's the correct fix. _2007-Mar-30 05:37:44 by anonymous:_ {linebreak} #1802, #2041 and #2270 are the same basic issue: librt should get linked into libsqlite3.so
#f2dcdc 2041 code active 2006 Oct anonymous 2007 Mar 4 4 sqlite3.pc on Solaris needs -lrt in "Libs:" entry On Solaris, to get fdatasync(), it's necessary to link with -lrt (the realtime library). I reported that issue a while back, and sqlite's configure has since become smart enough to look for fdatasync() in -lrt, and some of the sqlite Makefile targets know to at $(TLIBS) to the link line, to pick up any addtional libraries (like -lrt) that may be needed. The problem is that -lrt isn't added to the sqlite3.pc file that's generated, so other applications that use pkg-config and the sqlite3.pc to determine how to link against libsqlite3 don't know that they need to add -lrt. One fairly easy fix for the problem is to modify sqlite3.pc.in to also include @TARGET_LIBS@ in the Libs: line. That way, if anything is added to TARGET_LIBS by configure, it's automatically substituted into both the Makefile and sqlite3.pc. Still, I don't understand why libsqlite3 isn't directly linked against -lrt. It's the libsqlite.3.so.* that has the dependency on librt, not the sqlite3 shell, so I don't understand why $(TLIBS) is mentioned for the sqlite3 target instead of the libsqlite3.la target. I can provide a patch that adds @TARGET_LIBS@ to the Libs line for sqlite3.pc, or I can provide a patch that adds $(TLIBS) to the link line for libsqlite3.la and removes it from sqlite3. I just need to know which the developers prefer. Thanks! Tim _2006-Nov-22 15:09:25 by anonymous:_ {linebreak} I was having similar problems, but my build failures didn't occur until 'make test'. Unfortunately, @TARGET_LIBS@
did not work for me... Thankfully, adding $(TLIBS)
to the libsqlite3.la rule in the Makefile did. Thank you for reporting your fix! You've helped me greatly! -- Brett ---- _2007-Mar-30 05:37:16 by anonymous:_ {linebreak} #1802, #2041 and #2270 are the same basic issue: librt should get linked into libsqlite3.so
#e8e8bd 2231 new active 2007 Feb anonymous 2007 Mar 4 4 shell should ignore leading whitespace for meta commands The current shell.c doesn't ignore whitespace before meta commands. This is annoying since it ignores whitespace for sql and other commands and thus prevents indenting from being used. If a script is sent to someone like... sqlite3 data.db3 .header on create table ... .q
They can't just cut and paste the script into sqlite3 because of the whitespace. Patch is ... --- ..\sqlite-source-3_3_13\shell.c 2007-02-13 08:08:34.000000000 -0300 +++ shell.c 2007-02-15 04:18:05.726995200 -0300 @@ -934,22 +934,35 @@ } return val; } /* +** Determine if an input line begins with "." ignoring whitespace. +*/ +static int is_meta_command(const char *z){ + while( isspace((unsigned char)*z) ){ z++; } + return *z == '.'; +} + +/* ** If an input line begins with "." then invoke this routine to ** process that line. ** ** Return 1 on error, 2 to exit, and 0 otherwise. */ static int do_meta_command(char *zLine, struct callback_data *p){ - int i = 1; + int i = 0; int nArg = 0; int n, c; int rc = 0; char *azArg[50]; + /* Skip the "." prefix. + */ + while(zLine[i] != '.'){ i++; } + ++i; + /* Parse the input line into tokens. */ while( zLine[i] && nArgechoOn ) printf("%s\n", zLine); if( (zSql==0 || zSql[0]==0) && _all_whitespace(zLine) ) continue; - if( zLine && zLine[0]=='.' && nSql==0 ){ + if( zLine && is_meta_command(zLine) && nSql==0 ){ rc = do_meta_command(zLine, p); free(zLine); if( rc==2 ){ break; }else if( rc ){
_2007-Mar-01 21:53:33 by anonymous:_ {linebreak} Any possibility of this going in? A simple change. Full patch. Brings meta command whitespace processing to the same functionality as SQL (i.e. ignore leading whitespace). Submitting patches to opensource projects is so frustrating when there is no feedback.
#e8e8bd 2233 new active 2007 Feb anonymous 2007 Mar 4 3 extend xBestIndex in vtables to carry the values for each contraint It would be helpful if the xBestIndex method in virtual table carried the actual values for each constraint. This would allow clients of this call to more accurately set the estimatedCost of the query. The values are available in xFilter but the estimated cost has already been set and encoded by then. Thanks... At the time xBestIndex is called, the values are likely runtime variables or unbound host parameters and are thus unknown.
#e8e8bd 2258 new active 2007 Feb anonymous 2007 Mar 4 3 Include field name in check constraint failure message When a check constraint on a column fails SQLite just responds with "constraint failed". It'd be nice if it included the column name for which constraint failed and possibly the value that failed to pass the constraint. Thanks, Sam
#e8e8bd 2133 build active 2006 Dec anonymous 2007 Mar 4 4 meta ticket for outstanding autoconf issues Please add any outstanding autoconf issues to this ticket. Ticket #2082: UNIX: configure script doesn't enable loading of extensions Ticket #1906: HAVE_GMTIME_R and HAVE_LOCALTIME_R Ticket #1814: Autoconf support for MacOSX univeral binaries Ticket #2124: -ldl link issue Ticket #1966: Add a --disable-readline option to configure Ticket #2053: fdatasync unresolved symbol on solaris 10 Check-in [3709]: Add a new compile-time macro USE_PREAD64
#f2dcdc 2237 code active 2007 Feb anonymous 2007 Feb 4 4 Test suite regressions using Tcl 8.5 Tcl 8.5, SQLite 3.3.13 CVS printf-1.7.6... Expected: [Three integers: (1000000) ( f4240) (3641100)] Got: [Three integers: ( 1000000) ( f4240) (3641100)] printf-1.8.6... Expected: [Three integers: (999999999) (3b9ac9ff) (7346544777)] Got: [Three integers: ( 999999999) (3b9ac9ff) (7346544777)] printf-1.9.7... Expected: [Three integers: ( 0) ( 0x0) ( 0)] Got: [Three integers: ( 0) ( 0) ( 0)] tcl-1.6... Expected: [1 {syntax error in expression "x*"}] Got: [1 {invalid bareword "x" in expression "x*"; should be "$x" or "{x}" or "x(...)" or ...}]
#e8e8bd 2235 new active 2007 Feb anonymous 2007 Feb 4 3 Missing xml support in FTS2 for the snippet function The snippet function _may_ output invalid characters when used for an xml stream (like xhtml). Characters &, < and > need to be escaped (&, < >) in this context. The modification proposed is to add a boolean parameter to the snippet function to disable/enable the XML processing mode ; for example, given : =insert into poem (name, text) values ('test', 'Xml string with special < > & entities') ;= =select snippet(poem, '', '', '...', 1) from poem where text match 'xml' ;= output should be: =Xml string with special < > & entities= This modification does not affect the default behaviour of the snippet function. Patch included.
#e8e8bd 2224 new active 2007 Feb scouten 2007 Feb 4 4 Option to have one-bit "journal should exist" flag Per discussion with DRH: Would it be possible to have a one-bit flag in the header page of the DB file that signals that there _should_ be a journal file present. If you attempt to open a database with that flag set, but the journal file is not present, SQLite should fail to open the DB. _2007-Feb-09 13:47:44 by drh:_ {linebreak} Here is the issue: An application that uses SQLite for persistence is receiving database corruption reports from the field. The developers believe that the corruption occurs after a power failure or other crash leaves a hot journal file and then the users manually deletes the hot journal thinking that it is some garbage file left over from the crash. If there is a "journal should exist" flag in the database file and no journal is seen, that would indicate that the journal has been deleted or renamed and that the database has been corrupted. If the application can detect this, it might be able to locate the deleted journal in the trashcan and recover from the user error. Other ideas for addressing this problem: *: Change the "-journal" extension on the journal files to something like "-do-not-delete". *: Make the journal a hidden file. (The problem here is that if somebody goes to move the databaes file and the database has a hot journal, they would likely not know to move the journal too since it is not visible.) *: Change permissions on the journal file so that it is read-only. This doesn't prevent the journal from being deleted by a determined user, but it might at least give them a clue that this is not a file to be deleted without at least due consideration.
#e8e8bd 2222 build active 2007 Feb anonymous 2007 Feb 4 4 Type mismatch in fts2.c [5091] when compile as fastcall or stdcall I noticed a problem when compiling with Borland TurboC using either the -pr or -ps switches and I have a fix. The error is in reference to termDataCmp being passed to qsort. By changing the declaration of termDataCmp from: static int termDataCmp(const void *av, const void *bv){ to: static int __cdecl termDataCmp(const void *av, const void *bv){ the problem was resolved. I'm not sure this is a bug, but I thought I should report it just in case someone else runs into it. Kind Regards, Tom Olson
#f2dcdc 2182 code active 2007 Jan anonymous 2007 Jan 4 4 sqlite3BtreeGetMeta does not check the file format =sqlite3BtreeGetMeta= reads database page 1 directly from the pager layer, skipping all of the format checks in =lockBtree=. Thus, if the very first query you do against a database is "=PRAGMA user_version=" and the database isn't valid (in particular, if it is an sqlite 2 database) you will get a garbage result rather than an =SQLITE_NOTADB= or =SQLITE_CORRUPT= error. Demonstration: $ touch bug1.db # empty file $ dd if=/dev/zero of=bug2.db bs=100 count=1 # file header all zeroes $ sqlite2 bug3.db 'create table a(b);' # old-format database $ sqlite3 bug1.db 'pragma user_version' ; echo $? 0 0 $ sqlite3 bug2.db 'pragma user_version' ; echo $? 0 0 $ sqlite3 bug3.db 'pragma user_version' ; echo $? 1795162112 0 Contrast the sensible behavior if you do a =SELECT=: $ sqlite3 bug1.db 'select * from a'; echo $? SQL error: no such table: a 1 $ sqlite3 bug2.db 'select * from a'; echo $? SQL error: file is encrypted or is not a database 1 $ sqlite3 bug3.db 'select * from a'; echo $? SQL error: file is encrypted or is not a database 1 _2007-Jan-21 22:05:14 by anonymous:_ {linebreak} (Submitter:) Is there a reason why the file format check doesn't happen in sqlite3_open?
#f2dcdc 2165 code active 2007 Jan anonymous 2007 Jan 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; }
#e8e8bd 1722 new active 2006 Mar anonymous Unknown 2007 Jan 4 2 agregate sum() of strings i'd like to have something like sum() i agregate functions but to work with strings. I'd like to that that function would concate strings similar to summing in sum()e.g: SELECT sum(name || ',')FROM names GROUP BY ..... etc... :) I've heard that something like this is in postgresql?
#f2dcdc 2130 code active 2006 Dec anonymous 2006 Dec 4 4 replace "long long int" type with "sqlite_int64" defined in sqlite3.h As the typedef "typedef long long int sqlite_int64" is available in sqlite3.h. Please ensure that remaining references to "long long" use this typedef (for 32bit compilers): Searching for 'long long int'... sqlite3.h(89): typedef long long int sqlite_int64; sqlite3.h(90): typedef unsigned long long int sqlite_uint64; os_common.h(67):__inline__ unsigned long long int hwtime(void){ os_common.h(68): unsigned long long int x; os_common.h(74):static unsigned long long int g_start; sqliteInt.h(185):** cc '-DUINTPTR_TYPE=long long int' vdbe.c(365):__inline__ unsigned long long int hwtime(void){ vdbe.c(366): unsigned long long int x; 8 occurrence(s) have been found. thanks
#f2dcdc 2125 code new 2006 Dec anonymous 2006 Dec 4 4 SQLite strings/blobs limited to 1GB/2GB due to 'int' in api In several places it is claimed that SQLite doesn't have arbitrary limits - eg http://www.tcl.tk/community/tcl2004/Papers/D.RichardHipp/drh.html However the size of strings and blobs is limited due to using int in the APIs. Since int is 32 bit even on 64 bit platforms, that limits the size of individual strings to 2GB. For strings with a UTF16 database that means 1 billion characters. UTF8 strings are anywhere from 2 billion characters to 250 million worst case. When integrating SQLite into 64 bit code, I have to verify the sizes of all strings and blobs being passed in to ensure they don't overflow the signed 32 bit int. It would be nice if SQLite supported larger objects on 64 bit platforms. There may also be internal problems with the use of int everywhere. For example I could store a 1.5 billion byte UTF8 string and then request it back via the UTF16 api. _2006-Dec-21 23:47:22 by drh:_ {linebreak} On a 64-bit platform "int" is 64-bits. So apparently you can store blobs and strings larger than 2GiB. But SQLite is not designed for this and you would do much better to store such massive objects in a separate file then store the filename in the database. ---- _2006-Dec-22 08:37:46 by anonymous:_ {linebreak} {quote: On a 64-bit platform "int" is 64-bits} This is not true for all platforms. On MS Platforms: "int" is always 32 bit. ---- _2006-Dec-23 11:55:45 by anonymous:_ {linebreak} I don't know of *any* 64 bit platform where int is 64 bits (ie ILP64). Here are the sizes on x64 Linux with gcc: sizeof(int) = 4 sizeof(short) = 2 sizeof(long) = 8 sizeof(long long) = 8 sizeof(void*) = 8 There is a good list of what is supported on which platforms on Wikipedia. http://en.wikipedia.org/wiki/64-bit#64-bit_data_models Note "Most 64 bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, MacOS native compilers), Microsoft however decided to use the LLP64 model." Note that this means it is impossible to use sizes larger than 2GB with SQLite using int in the API. And while I agree that SQLite isn't the ideal solution for this much data, you do claim no arbitrary limits! Additionally 64 bit code has to ensure that it never gives more than a signed int worth of data. I also suspect that wierd things would happen if too large values are given. The usual way this is solved in other libraries is to use the size_t and ssize_t types which will always be sized appropriately for the platform. You could even define your own size types such as sqlite3_size_t (that is what Python did). ---- _2006-Dec-25 12:25:57 by anonymous:_ {linebreak} Actually I can categorically prove that the current SQLite code is broken and that *bad things will happen*. The front page of the site says "Sizes of strings and BLOBs limited only by available memory." Using a simple example, I looked at the implementation of sqlite3_value_text which takes an int. Lets assume -1 is passed in. That calls bindText which calls sqlite3VdbeMemSetStr. That ultimately executes this code: if( n<0 ){ pMem->n = strlen(z); pMem->n is of integer type, ie signed 32 bits on all current platforms (32 bit and 64 bit). The memory being pointed to could be more than 2GB on a 64 bit platform. strlen's return type is size_t which is 64 bits on 64 bit platforms. Consequently the strlen returned will have the top 32 bits ignore in the code above and SQLite will store a negative number or a number smaller than the actual length of the string. This means that data will be lost (positive truncation) or that wierd things will happen (negative truncation, several assert failures). Note that there is the potential for problems even on 32 bit machines. For example a 1.1GB UTF8 string can be supplied and then be requested in UTF16 which will be 2.2GB and make the ints go negative. I suggest one or more of the following fixes: *: Remove the claim on the front page about only being limited by memory since this isn't true *: Document that strings larger than 500MB (UTF8) should not be used and will result in undefined behaviour (worst case UTF8 to UTF16 expansion could be 4 bytes?) *: Document that blobs larger than 2GB should not be used and will result in undefined behaviour *: Switch to using size_t and ssize_t in the APIs. If using a signed type (eg ssize_t) for the string APIs then the 500MB limit still remains on 32 bit machines.
#f2dcdc 2128 code active 2006 Dec anonymous 2006 Dec 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.
#e8e8bd 2110 build active 2006 Dec anonymous 2006 Dec 4 3 Non-optional linking with readline makes sqlite3 binary GPL Currently, the sqlite3 binary is linked with libreadline support if it happens to be available at compile time. This may not always be desirable, because readline is licensed under GPL, and therefore the sqlite3 binary becomes GPL. Solution: There ought to be a configure script parameter --disable-readline (or something similar) to allow creating non-GPL binaries. _2006-Dec-17 16:11:21 by anonymous:_ {linebreak} Another solution would be to use editline instead, which is BSD licensed, from NetBSD project. Here is an autotool- and libtoolized port of it: {link: http://www.thrysoee.dk/editline/ }. It seems to even have a readline.h wrapper. Check the links there for {link: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date#dirlist upstream sources} and related projects. ---- _2006-Dec-17 16:34:45 by anonymous:_ {linebreak} This might work: env CFLAGS="-UHAVE_READLINE" ./configure ---- _2006-Dec-17 16:55:55 by anonymous:_ {linebreak} The -UHAVE_READLINE thing does not work because it is hardcoded into Makefile.in: # Compiler options needed for programs that use the readline() library. # READLINE_FLAGS = -DHAVE_READLINE=@TARGET_HAVE_READLINE@ @TARGET_READLINE_INC@ # The library that programs using readline() must link against. # LIBREADLINE = @TARGET_READLINE_LIBS@ ... sqlite3$(TEXE): $(TOP)/src/shell.c libsqlite3.la sqlite3.h $(LTLINK) $(READLINE_FLAGS) $(LIBPTHREAD) \ -o $@ $(TOP)/src/shell.c libsqlite3.la \ $(LIBREADLINE) $(TLIBS) You have to manually edit the generated Makefile to remove READLINE_FLAGS and LIBREADLINE.
#e8e8bd 2106 doc active 2006 Dec anonymous 2006 Dec 4 4 FtsOne wiki page neglects to mention Porter stemming http://www.sqlite.org/cvstrac/wiki?p=FtsOne claims that "the module does not perform stemming of any sort" when, in fact, FTS1 (in the 3.3.8 tarball and onwards) appears to fully support Porter stemming, using the same "tokenizer porter" syntax as FTS2.
#e8e8bd 2090 build active 2006 Nov anonymous 2006 Nov 4 3 Test corrupt2.test fails: Solaris While running 'make test', I had come across the following errors: ... corrupt2-1.1... Ok corrupt2-1.2... Expected: [1 {file is encrypted or is not a database}] Got: [0 {table abc abc 2 {CREATE TABLE abc(a, b, c)}}] corrupt2-1.3... Expected: [1 {file is encrypted or is not a database}] Got: [0 {table abc abc 2 {CREATE TABLE abc(a, b, c)}}] corrupt2-1.4... Expected: [1 {database disk image is malformed}] Got: [0 {table abc abc 2 {CREATE TABLE abc(a, b, c)}}] corrupt2-1.5... Expected: [1 {database disk image is malformed}] Got: [0 {table abc abc 2 {CREATE TABLE abc(a, b, c)}}] ... Turns out that SQLite was working fine, but TCL was not corrupting the database correctly (who would ever have thought I would want to?). Apparently the 'a' mode for opening a file in Solaris was resetting the position of a write to the end of a file before actually writing (this appears to be a point of contention on the TCL bug tracker). From the way the test is written, it appears that portions of the file were to be overwritten, instead of appending to the end of the file. I will attach a patch to corrupt2.test after posting this message which, instead of attempting an overwrite, writes individual portions of the database file at a time, with requested strings inserted (technically, replacing) into the file at the requested offsets. _2006-Nov-29 23:37:05 by anonymous:_ {linebreak} I should mention that this is SunOS 5.8, and TCL version 8.4.14. ---- _2006-Dec-05 10:22:08 by anonymous:_ {linebreak} I also get these errors (same tcl version but not SunOS). Have you tried a simpler patch by replacing the 'a' in the open calls by a 'r+'? This solved the problem for me. ---- _2007-Jan-23 19:55:08 by anonymous:_ {linebreak} That worked! Thank you so much!
#f2dcdc 2084 code active 2006 Nov anonymous 2006 Nov 4 3 Add API function mapping column decl string to SQLite type This is an API feature request. It would be nice to be able to obtain the SQLite type (e.g. SQLITE_INTEGER) from the declared column type string as returned by sqlite3_column_decltype. This was discussed briefly on the mailing list here: http://marc.10east.com/?l=sqlite-users&m=116422872301957&w=2 The function I have in mind is: int sqlite3_decltype_to_type(const char *decl) { Token decl_token; char aff_type; int col_type; decl_token.z = decl; if( decl_token.z ){ decl_token.n = strlen(decl_token.z); aff_type = sqlite3AffinityType(&decl_token); switch( aff_type ){ case SQLITE_AFF_INTEGER: col_type = SQLITE_INTEGER; break; case SQLITE_AFF_NUMERIC: /* falls through */ case SQLITE_AFF_REAL: col_type = SQLITE_FLOAT; break; case SQLITE_AFF_TEXT: col_type = SQLITE_TEXT; break; case SQLITE_AFF_NONE: col_type = SQLITE_BLOB; break; default: col_type = 0; /* unknown */ break; } } return col_type; } If this seems agreeable, I would be willing to put together a real patch. However, I would need some guidance on where it should go. I'm not sure what should happen when no type can be determined. _2006-Nov-26 22:32:45 by anonymous:_ {linebreak} According to the comment above the function sqlite3AffinityType: "If none of the substrings in the above table are found, SQLITE_AFF_NUMERIC is returned". The default condition in sqlite3_decltype_to_type will not be reached. ---- _2006-Nov-26 23:04:23 by anonymous:_ {linebreak} Thanks for pointing to that comment. Looks like SQLITE_AFF_NUMERIC is, for these purposes, unknown. So the case statement could be: switch( aff_type ){ case SQLITE_AFF_INTEGER: col_type = SQLITE_INTEGER; break; case SQLITE_AFF_REAL: col_type = SQLITE_FLOAT; break; case SQLITE_AFF_TEXT: col_type = SQLITE_TEXT; break; case SQLITE_AFF_NONE: col_type = SQLITE_BLOB; break; case SQLITE_AFF_NUMERIC: /* falls through */ default: col_type = 0; /* unknown */ break; } ---- _2006-Nov-27 02:43:06 by anonymous:_ {linebreak} Your first function was correct, it just had some unreachable code. There's no unknown affinity, in the absence of a match the affinity is assumed to be numeric: int sqlite3_decltype_to_type(const char *decl) { int type = SQLITE_FLOAT; if( decl ){ Token token; token.z = decl; token.n = strlen(token.z); switch( sqlite3AffinityType(&token) ){ case SQLITE_AFF_INTEGER: type = SQLITE_INTEGER; break; case SQLITE_AFF_TEXT: type = SQLITE_TEXT; break; case SQLITE_AFF_NONE: type = SQLITE_BLOB; break; default: break; } } return type; }
#f2dcdc 2083 code active 2006 Nov anonymous 2006 Nov 4 4 Give more detailed extension loading error information with dlerror When using loadable extensions. if dlopen returns an error then SQLite just gives a generic "unable to open shared library" message back. This makes it quite hard to diagnose problems. I suggest that on Unix platforms you append %s/dlerror() to the message and on Windows append %d/GetLastError()
#f2dcdc 2080 code active 2006 Nov anonymous 2006 Nov 4 4 Tranfering large BLOB data not efficient The current approach for tranfering BLOB data (sqlite3_bind_blob, sqlite3_column_blob) is not efficent for large BLOBs, since the whole BLOB data needs to be kept (multiple times?) in memory. It would be nice to have (additional) methods for streaming the (large) BLOB data to/from the database. Alternatively we could have methods for transfering the BLOB data in chunks. Same holds to some extend for large text fields. _2006-Dec-03 09:53:02 by anonymous:_ {linebreak} What is your definition of large? (1MB, 100MB, 1GB?) Note also that SQLite has an upper limit of 2GB on a field due to the use of signed int in the apis which is 32 bit even on 64 bit platforms. That will limit you to 2GB for blobs, 1GB for UTF-16 strings and somewhere inbetween for UTF-8 strings
#f2dcdc 2074 code active 2006 Nov anonymous 2006 Nov 4 4 feature request: .dump with page_size It would be useful for sqlite shell users to have a .dump command variant that would cause .dump to output the current database setting of "PRAGMA page_size;". Something similar to: sqlite> .dump2 PRAGMA page_size=16364; ...rest of dump... This way they can trivially preserve the page size when exporting/importing data from/to SQLite: sqlite3 old.db .dump2 | sqlite3 new.db without resorting to non-portable shell gymnastics: (echo -n "PRAGMA page_size=" ; sqlite3 old.db "PRAGMA page_size;" ; echo ";" ; ./sqlite3.exe old.db .dump) | sqlite3 new.db Perhaps other PRAGMA settings could also optionally be exported (legacy_file_format, cache size, etc).
#f2dcdc 2070 code active 2006 Nov anonymous 2006 Nov 4 4 No error for ambiguous result alias in WHERE clause This SELECT should result in an error since 'x' is ambiguous: select a x, 2*a x from (select 3 a union select 4 a) where x>3; 4|8 The current heuristic seems to be the first matching result set expression alias from left-to-right "wins". _2006-Nov-17 19:38:15 by anonymous:_ {linebreak} In this test case, the right-most ambiguous expression wins: CREATE TABLE t1(a); INSERT INTO t1 VALUES(3); INSERT INTO t1 VALUES(4); INSERT INTO t1 VALUES(5); select a*2 a, a from t1 where a>4; 10|5 It appears that table values take precedence over result set aliases in where clauses.
#f2dcdc 2068 code active 2006 Nov anonymous 2006 Nov 4 4 pkgIndex.tcl contains incomplete version number The pkgIndex.tcl file generated by sqlite 3.3.8 contains the line: package ifneeded sqlite3 3.3 ... Whereas the library actually provides version 3.3.8. In a 8.5 Tcl interpreter, this results in an error message when package require'd: attempt to provide package sqlite3 3.3 failed: package sqlite3 3.3.8 provided instead The solution seems to be to adjust the Makefile.in tcl_install target to pass $(RELEASE) rather than $(VERSION) to the tclinstaller.tcl script.
#f2dcdc 2063 code active 2006 Nov anonymous 2006 Nov 4 4 vtab_err.test fails if sqlite is compiled without -DSQLITE_MEMDEBUG I noticed that when running `make fulltest', vtab_err.test fails with an error message like this one (repeated over and over) if sqlite has been compiled without the option -DSQLITE_MEMDEBUG vtab_err-2.1... Error: invalid command name "sqlite_malloc_fail" altermalloc.test also has the same "sqlite_malloc_fail" command in it, but it doesn't cause an error because it skips the test if it detects that -DSQLITE_MEMDEBUG isn't available. I'll attach a patch that should fix it. The code is pretty much copied directly from altermalloc.test.
#f2dcdc 2062 code active 2006 Nov anonymous 2006 Nov 4 4 document 'pk' column of PRAGMA table_info() Comment in pragma.c and sqlite.org/pragma.html does not mention the sixth column of PRAGMA table_info().
#f2dcdc 2028 code active 2006 Oct anonymous 2006 Oct 4 2 FTS1: UNIQUE() expression and UPDATE command not working I'm working with tables, containing around 1,4 million entries (1GB file size). To allow faster fulltext search I tried FTS1 now. What I saw is: creating the virtual FTS1 table with one keyword "UNIQUE(code), reference, text, ..." I had the idea to have faster access to "code", because this entry is only one time existing in table. In my actual SQLITE table "UNIQUE" was good idea, because "UPDATE"ing of entries was much faster as without "UNIQUE" expression. Unfortunately, in that moemnt I use "UNIQUE" expression in fulltext table, the FTS1 table doesn't accept insertion of entries like "INSERT into receipe (code, reference, text) values ('4711', 'RefnotAvailable', 'Test');" So I removed the "UNIQUE" keyword, knowing that later "UPDATE" command to modify entries will be slower. So I built new table with additional FTS1 fulltext table. Then I tried to "UPDATE" one entry. In that moment the program stopped immediately working (WIN XP system), what means that the application stopped without comment and returned to desktop. I tried the same in SQLITE3.exe (command line program) but also that program suspended immediately after the UPDATE command (like "UPDATE Volltext SET code = '4710', reference = 'RefChanged', text = 'notext';" That seems to me to be a bug. By the way, creating fulltext table to search inside my whole database increased the filesize a lot (4 times). May be that is solved in FTS2? Last wish: Fulltext search like "foo*" to find "fool" and "foot" would be a really great improvement. Best regards Ingo _2006-Oct-23 13:56:59 by anonymous:_ {linebreak} Ooops, as I saw today, also "DELETE" statements are causing SQLITE to stop working (crash). Program returns to Desktop on WIN XP after DELETE command.
#f2dcdc 2026 code active 2006 Oct anonymous 2006 Oct 4 5 \n in .output is not allowed even with quote *.output drive:\nabc.txt* {linebreak} *.output e:\new0.txt* {linebreak} *.output z:\new1.txt* {linebreak} *.output "c:\new2.txt"* will result an error omitting the *\* will just put the file in the same folder to the sqlite3.exe (doesnt help) solve it by replace *\* by */* _2006-Oct-15 21:28:55 by anonymous:_ {linebreak} How about c:\\new.txt? ---- _2006-Oct-16 11:49:58 by anonymous:_ {linebreak} How about "c:/new.txt"?
#f2dcdc 2014 code active 2006 Oct anonymous 2006 Oct anonymous 4 3 Enhancement Req: CREATE [TEMP | TEMPORARY] VIRTUAL TABLE Regarding the experimental VIRTUAL TABLE implementation, I believe it would of benefit to provide a "temp", or volatile construct when working with them. -- From a SQL syntax perspective, adding an optional keyword "TEMP" to the declaration: CREATE [TEMP | TEMPORARY] VIRTUAL TABLE. -- From a code perspective, I would envision this to invoke xCreate as it does now, but when the database is closed, the table is automatically dropped like any temp table, and xDestroy invoked rather than xDisconnect. One sticky point I can picture is behavior when multiple opens exist to a single database from the same process space. Since virtual tables are already reference counted (in SQLite 3.3.8), perhaps the reference count could be made to span database handles and be bubbled up to the process level instead. That would allow the table to be CREATEd on one handle, CONNECTed on a second handle, then DISCONNECTed/DESTROYed based on the process-wide reference count. I feel that there are numerous implementation possibilities for this. Having no option to auto-drop a virtual table can lead to stray module references, creating SQLite database files that cannot be properly utilized if the vtable module is not available. Of course this can be implemented by the application calling DROP TABLE on it's own, but an embedded solution that takes care of it seems more 'proper' given the thought that goes into SQLite as a whole.
#f2dcdc 2013 code active 2006 Oct anonymous 2006 Oct drh 4 3 Autoincrement increments on failing INSERT OR IGNORE % package require sqlite3 3.3.8 % sqlite3 db "" % db eval "CREATE TABLE test (counter INTEGER PRIMARY KEY AUTOINCREMENT, value text NOT NULL UNIQUE)" % db eval "INSERT INTO test VALUES(4, 'hallo')" % db eval "SELECT * FROM sqlite_sequence" test 4 % db eval "INSERT OR IGNORE INTO test(value) VALUES('hallo')" % db eval "SELECT * FROM sqlite_sequence" test 5 ---> there has no dataset been inserted but the AUTOINCREMENT-counter is incremented % db eval "INSERT OR IGNORE INTO test VALUES(4, 'hallo')" % db eval "SELECT * FROM sqlite_sequence" test 5 ---> right behavior: no inserted dataset and no incrementation This maybe could be a problem if the "INSERT OR IGNORE" happens very often.
#f2dcdc 2012 code active 2006 Oct anonymous 2006 Oct 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.
#f2dcdc 1960 code active 2006 Sep anonymous 2006 Sep 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.
#e8e8bd 1959 new active 2006 Sep anonymous 2006 Sep 4 3 Unblockable TEMP TABLES TEMP TABLES locks the complete database as long as a prepared stmt is running at the main database. Temp Tables are in separate files... so I hope it can be changed without big problems. The new driver for OpenOffice.org needs temp tables that won't lock the complete database because of cached resultsets. It only can be emulate it with "attach a database, copy data, detach". But the problem is that the API of OOo needs to change the cached resultset. It isn't possible to add this without temporary tables. So the driver could use sqlite3_update_hook() to know when he needs to reload the resultset. Thanks
#f2dcdc 1958 code active 2006 Sep anonymous 2006 Sep 4 4 some printf tests fail with Tcl 8.5a5, ok with Tcl 8.4 Tcl 8.5a5: printf-1.7.6... Expected: [Three integers: (1000000) ( f4240) (3641100)] Got: [Three integers: ( 1000000) ( f4240) (3641100)] printf-1.8.6... Expected: [Three integers: (999999999) (3b9ac9ff) (7346544777)] Got: [Three integers: ( 999999999) (3b9ac9ff) (7346544777)] printf-1.9.7... Expected: [Three integers: ( 0) ( 0x0) ( 0)] Got: [Three integers: ( 0) ( 0) ( 0)] Tcl 8.4: printf-1.7.6... Ok printf-1.8.6... Ok printf-1.9.7... Ok _2006-Sep-05 02:27:00 by anonymous:_ {linebreak} This is not directly related to the ticket, but concerns the same test file... Why are these tests not run on windows? I thought sqlite3_mprintf() is platform independent. if {$::tcl_platform(platform)!="windows"} { set m 1 foreach {a b} {1 1 5 5 10 10 10 5} { set n 1 foreach x {0.001 1.0e-20 1.0 0.0 100.0 9.99999 -0.00543 -1.0 -99.99999} { do_test printf-2.$m.$n.1 [subst { sqlite3_mprintf_double {A double: %*.*f} $a $b $x }] [format {A double: %*.*f} $a $b $x] do_test printf-2.$m.$n.2 [subst { sqlite3_mprintf_double {A double: %*.*e} $a $b $x }] [format {A double: %*.*e} $a $b $x] do_test printf-2.$m.$n.3 [subst { sqlite3_mprintf_double {A double: %*.*g} $a $b $x }] [format {A double: %*.*g} $a $b $x] do_test printf-2.$m.$n.4 [subst { sqlite3_mprintf_double {A double: %d %d %g} $a $b $x }] [format {A double: %d %d %g} $a $b $x] do_test printf-2.$m.$n.5 [subst { sqlite3_mprintf_double {A double: %d %d %#g} $a $b $x }] [format {A double: %d %d %#g} $a $b $x] do_test printf-2.$m.$n.6 [subst { sqlite3_mprintf_double {A double: %d %d %010g} $a $b $x }] [format {A double: %d %d %010g} $a $b $x] incr n } incr m } } ;# endif not windows
#f2dcdc 1953 code active 2006 Sep anonymous TclLib 2006 Sep 4 3 Fix for false 64-bit comparisons "make test" failures on Cygwin The trivial patch below allows Cygwin to correctly pass all (two dozen or so) 64-bit integer-related tests in "make test". It does so by treating all 64-bit integer SQL results as strings. (Note: SQLite has always produced correct 64-bit integer results, it's just that the test harness on Cygwin produces false failures without this patch.) There is no impact to other platforms, and allows us unfortunate Windows users to be useful members of society. RCS file: /sqlite/sqlite/src/tclsqlite.c,v retrieving revision 1.172 diff -u -r1.172 tclsqlite.c --- src/tclsqlite.c 31 Aug 2006 15:07:15 -0000 1.172 +++ src/tclsqlite.c 1 Sep 2006 17:27:44 -0000 @@ -432,7 +432,12 @@ if( v>=-2147483647 && v<=2147483647 ){ pVal = Tcl_NewIntObj(v); }else{ +#ifndef __CYGWIN__ pVal = Tcl_NewWideIntObj(v); +#else + int bytes = sqlite3_value_bytes(pIn); + pVal = Tcl_NewStringObj((char *)sqlite3_value_text(pIn), bytes); +#endif } break; } @@ -1420,7 +1425,11 @@ if( v>=-2147483647 && v<=2147483647 ){ pVal = Tcl_NewIntObj(v); }else{ +#ifndef __CYGWIN__ pVal = Tcl_NewWideIntObj(v); +#else + pVal = dbTextToObj((char *)sqlite3_column_text(pStmt, i)); +#endif } break; } Example test failures before patch: $ ./testfixture.exe test/misc2.testmisc2-1.1... Ok misc2-1.2... Ok misc2-2.1... Ok misc2-2.2... Ok misc2-2.3... Ok misc2-3.1... Ok misc2-4.1... Expected: [4000000000] Got: [-294967296] misc2-4.2... Expected: [4000000000 2147483648] Got: [-294967296 -2147483648] misc2-4.3... Ok misc2-4.4... Expected: [1 2147483648 2147483647] Got: [1 -2147483648 2147483647] misc2-4.5... Expected: [1 4000000000 2147483648 2147483647] Got: [1 -294967296 -2147483648 2147483647] misc2-4.6... Expected: [1 2147483647 2147483648 4000000000] Got: [1 2147483647 -2147483648 -294967296] misc2-5.1... Ok misc2-6.1... Ok misc2-7.1... Ok misc2-7.2... Ok misc2-7.3... Ok misc2-7.4... Ok misc2-7.5... Ok misc2-7.6... Ok misc2-7.7... Ok misc2-7.8... Ok misc2-8.1... Ok misc2-9.1... Ok misc2-9.2... Ok misc2-9.3... Ok misc2-10.1... Ok Thread-specific data deallocated properly 5 errors out of 28 tests Failures on these tests: misc2-4.1 misc2-4.2 misc2-4.4 misc2-4.5 misc2-4.6 After patch applied: $ ./testfixture.exe test/misc2.testmisc2-1.1... Ok misc2-1.2... Ok misc2-2.1... Ok misc2-2.2... Ok misc2-2.3... Ok misc2-3.1... Ok misc2-4.1... Ok misc2-4.2... Ok misc2-4.3... Ok misc2-4.4... Ok misc2-4.5... Ok misc2-4.6... Ok misc2-5.1... Ok misc2-6.1... Ok misc2-7.1... Ok misc2-7.2... Ok misc2-7.3... Ok misc2-7.4... Ok misc2-7.5... Ok misc2-7.6... Ok misc2-7.7... Ok misc2-7.8... Ok misc2-8.1... Ok misc2-9.1... Ok misc2-9.2... Ok misc2-9.3... Ok misc2-10.1... Ok Thread-specific data deallocated properly 0 errors out of 28 tests Failures on these tests: The only new regression on Cygwin is this test, which is expected: types3-2.3... Expected: [wideInt] Got: [] _2006-Sep-01 18:55:25 by drh:_ {linebreak} The TCL interface is more than just part of the test harness. A lot of people use the TCL interface as part of their applications. I believe what this patch does is mask a real problem. I would prefer to fix the underlying problem, not just treat the symptom. ---- _2006-Sep-02 02:48:57 by anonymous:_ {linebreak} I have no interest in fixing bugs in Tcl itself on Cygwin. I just want to reliably build and test SQLite. The proposed fix is purely pragmatic and is intended only for the test harness. Indeed, when dealing with testing only, the fix is not Cygwin-specific and would work on any platform. The test harness under stock Cygwin as it stands simply does not work for 64 bit values. When you see such a failure you assume that SQLite is in error. Perhaps a compromise can be made and the code fix in question can be wrapped in #ifdef SQLITE_TESTFIXTURE or equivalent instead of #ifdef __CYGWIN__. I would hate to see someone else waste any time on this trivially fixable issue. ---- _2006-Sep-02 13:27:08 by drh:_ {linebreak} Perhaps you could put an "if" statement in the test scripts that skipped over the tests that do not work if running under cygwin. You can probably figure out if you are running under cygwin by looking at elements of the tcl_platform array. ---- _2006-Sep-02 13:48:56 by drh:_ {linebreak} I retract my previous suggestion. I do not want such patches in the SQLite source tree. I will resist any patches such as shown here because they are really hacks to work around a faulty Tcl build on Cygwin. The correct way to fix this is to fix the Tcl build for Cygwin. This is probably as simple as download a copy of Tcl and recompiling. I'm curious to know why the default Tcl build for Cygwin only supports 32-bit integers. Is there some problem with 64-bit integer support on Cygwin? The patch shown in the Description section above is not good because it presumes that Cygwin will always be broken. I think a better assumption is that Cygwin will get fixed. And I do not want to cripple the TCL interface to work around a bug that is not related to SQLite and which might not exist on every system. That is *so* wrong. I will be willing to put in a test that checks for the cygwin brokenness and prints a warning to the user. Perhaps something like this: if {"*[db eval {SELECT 10000000000}]*"!="*10000000000*"} { puts "*********** WARNING *************" puts "Your build of TCL only supports 32-bit integers." puts "This will cause many test failures. To run these" puts "tests you must install a version of TCL that supports" puts "64-bit integers." exit } The question is, does that test correctly detect the broken Cygwin? Since I have no ready access to a windows machine, I have no way of testing it. ---- _2006-Sep-02 14:06:28 by anonymous:_ {linebreak} Then you would have an on-going maintenance issue with future tests. If'ing out valid tests just masks the problem and defeats the purpose of having a test regression suite. If a test fails legitimately, it should be reported as such. But these particular 64-bit tests work correctly if the simple proposed patch to the test harness is checked in. There is nothing wrong with the tests themselves - just the test harness on certain platforms for which Tcl does support 64-bit integers for whatever reason. Is the purpose of the test suite to test SQLite or Tcl implementations? I know that Cygwin is a considered a tier "C" platform for SQLite, but appreciate that from a Cygwin environment me and many others have reported at least couple of dozen non-platform-specific SQLite bugs over the past year. You probably have as many or more Cygwin users on the mailing list than Mac OSX users. Why put up artificial ideological roadblocks? ---- _2006-Sep-02 14:10:35 by anonymous:_ {linebreak} Please do not check the "Your build of TCL only supports 32-bit integers". It is couter-productive to exit when the great majority of tests will pass. Such a check will basically exclude stock Cygwin installs from testing SQLite. Given the choice between having a broken test harness and this TCL 32-bit check, it is more useful to have a broken test harness. ---- _2006-Sep-04 01:25:00 by anonymous:_ {linebreak} {link: http://sourceforge.net/tracker/index.php?func=detail&aid=1551762&group_id=10894&atid=110894 Cygwin Tcl 8.5 64-bit integer math bug report} {link: http://sourceforge.net/tracker/download.php?group_id=10894&atid=110894&file_id=191898&aid=1551762 Cygwin Tcl 8.5a5 64-bit integer math fix}
#e8e8bd 1938 build active 2006 Aug anonymous 2006 Aug 4 5 Cygwin compilation of v3 fails make install leads to this: [UTEKLIFEBOOK] ~/MyDocuments/dl/sqlite-3.3.7 > make install tclsh ./tclinstaller.tcl 3.3 can't read "env(DESTDIR)": no such variable _2006-Aug-25 13:24:19 by anonymous:_ {linebreak} Looking at your log file you can see that sqlite3.exe was built successfully. Tcl is an optional component of SQLite. All you need is: ./configure && make sqlite3.exe Or install TCL via Cygwin setup.exe. ---- _2006-Sep-26 17:02:54 by anonymous:_ {linebreak} Why not build with this? *: ./configure --disable-tcl *: make *: make install It works for me.
#e8e8bd 1942 new active 2006 Aug anonymous 2006 Aug 4 4 select without left join with the *= operator Enhancement request for support *=/=* operator in select queries. It's more easier to write SQL queries without left/right join by using *=/=* operator. Mentionned on Unsupported Wiki page : http://www.sqlite.org/cvstrac/wiki?p=UnsupportedSql * 2006.03.06 : select without left join with the *= operator SELECT t1.code, t2.code FROM table1 t1, table2 t2 WHERE t1.t2_ref_id *= t2.id This is Sybase ASE syntax. Use LEFT JOIN or RIGHT JOIN instead.
#e8e8bd 1935 event active 2006 Aug anonymous Parser 2006 Aug 4 4 GROUP BY and ORDER BY constant expressions valid? I'm not sure what other databases do in this situation, or whether a constant expression should be deemed a constant in ORDER BY and GROUP BY and result in an error. CREATE TABLE t1(a,b); INSERT INTO "t1" VALUES(1, 2); INSERT INTO "t1" VALUES(1, 3); INSERT INTO "t1" VALUES(2, 3); INSERT INTO "t1" VALUES(2, 4); INSERT INTO "t1" VALUES(2, 5); -- as expected select a, b from t1 group by 0; SQL error: GROUP BY column number 0 out of range - should be between 1 and 2 -- ??? select a, b from t1 group by 0/1; 2|5 select a, b from t1 group by 0.0; 2|5 select a, b from t1 order by 13/2; 1|2 1|3 2|3 2|4 2|5 select a, b from t1 group by 3/9 order by 1/9, 7.0, 0.4-3; 2|5 _2006-Aug-26 07:26:06 by anonymous:_ {linebreak} The integer is the column number.
#e8e8bd 1907 new active 2006 Aug anonymous 2006 Aug 4 4 date and time types I would like to have datetime types in sqlite (date, datetime, interval). as far as I understood of sqlite, the declared type used in the create table statement is just a hint, and the data is stored with its own type description. this makes it impossible to store a date into any field, unless type checking, conversion and validation is performed by the client side. implementing type checking and conversion on the client side would mean that the dynamic typing in sqlite goes lost for that applications. _2006-Aug-05 13:49:35 by anonymous:_ {linebreak} Also, the way SQLite currently stores datetimes is not space efficient (stored as text) and there is no standard format between different SQLite applications. But I can't see a way to improve this situation without breaking backwards compatability.
#e8e8bd 1895 doc active 2006 Jul anonymous 2006 Jul anonymous 4 3 IS operator not documented Hello, I tried to work with varchar fields having NULL values. However, I was not able to find the right operator to catch such values, and none of the operators mentionend in datatype3.html seemed to help. Finally I tried "is null" (or IS NOT NULL) and well, that seems to do what I want. But there are questions: *: is this an intended feature? *: if yes, can I rely on having it in the future versions? *: if this is not an intended feature, what is the right way to match NULL values? *: if that's just a documentation problem, will the documentation be updated? _2006-Jul-19 19:02:17 by anonymous:_ {linebreak} It's part of the SQL standard. "IS" isn't really an operator; it's an optional token that's part of the NULL and NOT NULL predicates.
#f2dcdc 1872 code active 2006 Jun anonymous 2006 Jun 4 3 sqlite3_open doesn't support RFC1738 format for filename sqlite3_open only supports UTF-8 encoding as a format for its filename argument (http://www.sqlite.org/capi3ref.html#sqlite3_open). If your application receives a RFC1738 encoded URL for filename, that has to be UTF-8-encoded for use in SQLite. It would be nice if that could be instead passed directly to sqlite3_open. Is RFC1738 URL decoding support planned for SQLite? (RFC1738 link: http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc1738.html)
#e8e8bd 1869 doc active 2006 Jun anonymous Unknown 2006 Jun anonymous 4 4 Website typo http://www.sqlite.org/capi3ref.html#sqlite3_exec has this: "As an example, suppose the query result where this table:" Instead of "where," "were" should have been used.
#e8e8bd 1837 new active 2006 Jun anonymous Pager 2006 Jun 4 4 Deadlock detection would be best reported using explicit error code. As discussed in email (*), an explicit deadlock error code might be beneficial for an application to detect and recover from deadlock. Deadlock is different to SQLITE_BUSY, and should be notified as such (IMHO). (*) http://www.mail-archive.com/sqlite-users%40sqlite.org/msg15979.html _2006-Jun-12 11:23:49 by drh:_ {linebreak} Changing the integer return code would be not be a backwards compatible change, so that approach must be rejected. But we will consider some mechanism to make it easier for programmers to figure out that they are dealing with deadlock and not a temporary delay. ---- _2006-Jun-12 15:43:59 by anonymous:_ {linebreak} Is there a fatal return code? If so, perhaps it could be overloaded with an additional function to determine if this 'fatal' error is actually a deadlock. Deadlocks are a common return code from almost every database I've ever programmed for. I am not sure how you can work around it otherwise.
#e8e8bd 1833 doc active 2006 Jun anonymous Unknown 2006 Jun drh 4 3 PRAGMA legacy_file_format not documented [2922] introduces the *legacy_file_format* pragma, but it's not documented anywhere. At the very least, it should be mentioned in /sqlite/www/pragma.tcl, unless there's some better way to have a SQLite 3.3.5 (or so) generate databases usable by older versions of SQLite 3 (Debian stable, for example, ships with 3.2.1).
#e8e8bd 1812 new active 2006 May anonymous 2006 May 4 1 alter table add column default current_timestamp I wish I can alter my schema and add column with non-constant default. How difficult is this compared with constant default?
#f2dcdc 1804 code active 2006 May anonymous Unknown 2006 May 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.
#e8e8bd 1789 doc active 2006 May anonymous Unknown 2006 May drh 4 4 sqlite3_result_error() not adequately documented Documentation for =sqlite3_result_error()= and friends says "operation of these routines is very similar to the operation of sqlite3_bind_blob() and its cousins", but none of the bind routines are really that similar. So it's not obvious from existing documentation whether the =int= argument is a string length or, say, a =SQLITE_= error code, or a static/transient flag. A glance at /sqlite/src/func.c _suggests_ that it's a static/transient flag, but it's not entirely clear (and if it is, why isn't the signature similar to =sqlite3_result_text()=?) =sqlite3.h= and =capi3.html= should probably have a little more discussion about returning error situations from user-defined functions. c.
#e8e8bd 1786 warn active 2006 Apr anonymous 2006 Apr 4 4 Yet another list of compiler warnings. I compiled sqlite 3.3.5 from sqlite-source-3_3_5.zip using msvc 2005. Similar warnings show up with both gcc4 on mac (and I assume other platforms) and using sun studio on both solaris and linux. On msvc I set to the higest warning level, then disabled the following warnings which are in my opinion not real issues (4311;4312;4100;4210;4127). Most of the warnings follow the general form of int to smaller size int truncation without explicit cast, float or double sized type to int without explicit cast, or comparison of a signed to unsigned type. The following is my build log showing the warnings: ------ Rebuild All started: Project: sqlite, Configuration: Debug Win32 ------ {linebreak} Deleting intermediate and output files for project 'sqlite', configuration 'Debug|Win32' {linebreak} Compiling... {linebreak} alter.c {linebreak} analyze.c {linebreak} attach.c {linebreak} c:\src\sqlite-source-3_3_5\attach.c(314) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} auth.c {linebreak} btree.c {linebreak} c:\src\sqlite-source-3_3_5\btree.c(449) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(450) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(453) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(454) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(455) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(456) : warning C4244: '=' : conversion from 'u32' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(538) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(540) : warning C4244: 'function' : conversion from 'i64' to 'u32', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(831) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(898) : warning C4018: '<' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(955) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(961) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(967) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(986) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(988) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(990) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1174) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1226) : warning C4244: '-=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1239) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1303) : warning C4244: '+=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1316) : warning C4244: '-=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1342) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1343) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1344) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1349) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1350) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1353) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1354) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1356) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1405) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1407) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1435) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1460) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1465) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1467) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1468) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1661) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1663) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1692) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1865) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1867) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1949) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(1950) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2056) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2206) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2267) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2374) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2397) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2402) : warning C4018: '>' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2402) : warning C4018: '<=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2405) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2418) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2475) : warning C4389: '!=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2814) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2990) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(2996) : warning C4018: '>' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3129) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3136) : warning C4018: '>' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3184) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3448) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3448) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3450) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3452) : warning C4244: 'function' : conversion from 'i64' to 'u32', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3453) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3453) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3817) : warning C4018: '>' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3854) : warning C4389: '!=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3859) : warning C4389: '!=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3869) : warning C4389: '!=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(3970) : warning C4018: '>' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(4029) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(4038) : warning C4244: '+=' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(4040) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data {linebreak} {linebreak} c:\src\sqlite-source-3_3_5\btree.c(4117) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(4242) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(4259) : warning C4018: '<=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(4322) : warning C4244: '-=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(4331) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(4611) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(4695) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5070) : warning C4018: '<=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5499) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5591) : warning C4018: '>' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5725) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5768) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5774) : warning C4389: '!=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5895) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5896) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5897) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5898) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5899) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5905) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5924) : warning C4244: '+=' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5941) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5948) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5958) : warning C4244: '=' : conversion from 'u32' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5962) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(6281) : warning C4244: '+=' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\btree.c(6444) : warning C4389: '!=' : signed/unsigned mismatch {linebreak} {linebreak} c:\src\sqlite-source-3_3_5\btree.c(6448) : warning C4389: '==' : signed/unsigned mismatch {linebreak} build.c {linebreak} c:\src\sqlite-source-3_3_5\build.c(35) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(183) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(262) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(320) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(347) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(363) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(522) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(552) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(556) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(620) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(622) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\build.c(955) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1127) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1128) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1216) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1302) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1319) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1324) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1330) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1481) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1531) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1538) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1555) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(1624) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2036) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2073) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2081) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2082) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2083) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2109) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2342) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2345) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2354) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2361) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2382) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2383) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2429) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2490) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\build.c(2873) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} callback.c {linebreak} c:\src\sqlite-source-3_3_5\callback.c(28) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\callback.c(59) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\callback.c(160) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\callback.c(301) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} complete.c {linebreak} date.c {linebreak} c:\src\sqlite-source-3_3_5\date.c(204) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(233) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(234) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(339) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(340) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(343) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(344) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(345) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(346) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(360) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(361) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(363) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(407) : warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(413) : warning C4244: '=' : conversion from 'double' to 'time_t', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(459) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(508) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(514) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(590) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(606) : warning C4244: '+=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(612) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(618) : warning C4244: '+=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(812) : warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(813) : warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(815) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(827) : warning C4244: '=' : conversion from 'double' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(839) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(844) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(848) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\date.c(849) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} delete.c {linebreak} c:\src\sqlite-source-3_3_5\delete.c(71) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\delete.c(165) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} expr.c {linebreak} c:\src\sqlite-source-3_3_5\expr.c(201) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\expr.c(346) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\expr.c(1158) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\expr.c(1160) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data {linebreak} func.c {linebreak} c:\src\sqlite-source-3_3_5\func.c(221) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\func.c(234) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\func.c(866) : warning C4244: 'initializing' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\func.c(867) : warning C4244: 'initializing' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\func.c(868) : warning C4244: 'initializing' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\func.c(869) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\func.c(1052) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\func.c(1074) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\func.c(1096) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\func.c(1098) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} hash.c {linebreak} c:\src\sqlite-source-3_3_5\hash.c(35) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\hash.c(39) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\hash.c(105) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} insert.c {linebreak} c:\src\sqlite-source-3_3_5\insert.c(993) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\insert.c(996) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} legacy.c {linebreak} main.c {linebreak} c:\src\sqlite-source-3_3_5\main.c(413) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\main.c(446) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\main.c(458) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\main.c(773) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\main.c(783) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\main.c(787) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\main.c(1102) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} opcodes.c {linebreak} os.c {linebreak} os_unix.c {linebreak} os_win.c {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(781) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(785) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(873) : warning C4244: 'initializing' : conversion from 'i64' to 'LONG', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(874) : warning C4244: 'initializing' : conversion from 'i64' to 'LONG', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(880) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(915) : warning C4244: 'initializing' : conversion from 'i64' to 'LONG', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(919) : warning C4244: 'function' : conversion from 'i64' to 'LONG', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(959) : warning C4244: '=' : conversion from 'int' to 'short', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(1135) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(1199) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} Generating Code... {linebreak} c:\src\sqlite-source-3_3_5\os_win.c(856) : warning C4701: potentially uninitialized local variable 'wrote' used {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5424) : warning C4701: potentially uninitialized local variable 'pNext' used {linebreak} c:\src\sqlite-source-3_3_5\btree.c(5424) : warning C4701: potentially uninitialized local variable 'szNext' used {linebreak} Compiling... {linebreak} pager.c {linebreak} c:\src\sqlite-source-3_3_5\pager.c(424) : warning C4244: '=' : conversion from 'u32' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(425) : warning C4244: '=' : conversion from 'u32' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(426) : warning C4244: '=' : conversion from 'u32' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(427) : warning C4244: '=' : conversion from 'u32' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(469) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(554) : warning C4018: '<' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\pager.c(750) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(972) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1075) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1080) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1289) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1297) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1307) : warning C4018: '<' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1423) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1440) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1498) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1499) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1500) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1617) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1647) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1648) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1662) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1663) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1664) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1666) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1799) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1805) : warning C4244: 'return' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1890) : warning C4018: '<=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1927) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(2268) : warning C4018: '<=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\pager.c(2520) : warning C4389: '==' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\pager.c(2637) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pager.c(3009) : warning C4389: '!=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\pager.c(3628) : warning C4018: '<=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\pager.c(3629) : warning C4389: '!=' : signed/unsigned mismatch {linebreak} parse.c {linebreak} parse.c(1309) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} parse.y(154) : warning C4244: '=' : conversion from '__w64 unsigned int' to 'unsigned int', possible loss of data {linebreak} parse.y(229) : warning C4244: '=' : conversion from '__w64 int' to 'unsigned int', possible loss of data {linebreak} parse.y(233) : warning C4244: '=' : conversion from '__w64 int' to 'unsigned int', possible loss of data {linebreak} parse.y(379) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} parse.y(451) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} parse.y(532) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} parse.y(536) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} parse.y(871) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} parse.y(880) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} parse.y(919) : warning C4244: '=' : conversion from '__w64 unsigned int' to 'unsigned int', possible loss of data {linebreak} parse.c(3271) : warning C4244: 'function' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} parse.c(3282) : warning C4244: 'function' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} pragma.c {linebreak} c:\src\sqlite-source-3_3_5\pragma.c(49) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pragma.c(118) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\pragma.c(443) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} prepare.c {linebreak} c:\src\sqlite-source-3_3_5\prepare.c(274) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\prepare.c(577) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} printf.c {linebreak} c:\src\sqlite-source-3_3_5\printf.c(413) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(426) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(493) : warning C4244: '=' : conversion from 'int' to 'etByte', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(503) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(517) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(540) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(543) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(544) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(551) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(579) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(581) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(596) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(620) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(621) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(644) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\printf.c(647) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} random.c {linebreak} c:\src\sqlite-source-3_3_5\random.c(68) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\random.c(83) : warning C4244: '+=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\random.c(86) : warning C4244: '+=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\random.c(97) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} select.c {linebreak} c:\src\sqlite-source-3_3_5\select.c(69) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\select.c(183) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\select.c(557) : warning C4244: 'initializing' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\select.c(976) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\select.c(1004) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\select.c(1744) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\select.c(2231) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} shell.c {linebreak} c:\src\sqlite-source-3_3_5\shell.c(387) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(407) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(409) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(586) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(587) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(738) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(838) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(880) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(941) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(961) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(1005) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(1035) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(1042) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(1056) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(1148) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(1236) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(1353) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(1472) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(1477) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\shell.c(1698) : warning C4013: 'access' undefined; assuming extern returning int {linebreak} table.c {linebreak} tokenize.c {linebreak} trigger.c {linebreak} c:\src\sqlite-source-3_3_5\trigger.c(113) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\trigger.c(172) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\trigger.c(260) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\trigger.c(265) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\trigger.c(454) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\trigger.c(476) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\trigger.c(540) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\trigger.c(631) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data {linebreak} update.c {linebreak} c:\src\sqlite-source-3_3_5\update.c(155) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} utf.c {linebreak} c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(326) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(333) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(336) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(344) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(350) : warning C4244: '=' : conversion from 'int' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(353) : warning C4244: '=' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(501) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\utf.c(549) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} util.c {linebreak} c:\src\sqlite-source-3_3_5\util.c(724) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\util.c(756) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\util.c(870) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\util.c(1040) : warning C4244: '=' : conversion from 'long double' to 'double', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\util.c(1041) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\util.c(1226) : warning C4244: '=' : conversion from 'u64' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\util.c(1229) : warning C4244: '=' : conversion from 'u64' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\util.c(1236) : warning C4244: '=' : conversion from 'u64' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\util.c(1355) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\util.c(1360) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} vacuum.c {linebreak} c:\src\sqlite-source-3_3_5\vacuum.c(131) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} vdbe.c {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(662) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(677) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(693) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(752) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(1601) : warning C4244: '=' : conversion from 'int' to 'char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(1931) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(1957) : warning C4018: '<' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(1997) : warning C4018: '>=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2004) : warning C4018: '>=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2013) : warning C4018: '<' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2028) : warning C4018: '<' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2312) : warning C4244: 'initializing' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2313) : warning C4244: 'initializing' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2450) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2454) : warning C4244: '=' : conversion from 'i64' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2554) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2572) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2614) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2615) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2628) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2788) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(2805) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(3064) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(3445) : warning C4244: '=' : conversion from 'i64' to 'u32', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(3546) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(3595) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(3601) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(3641) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(3809) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(4118) : warning C4244: '=' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(4131) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbe.c(4514) : warning C4244: 'initializing' : conversion from 'int' to 'u8', possible loss of data {linebreak} vdbeapi.c {linebreak} c:\src\sqlite-source-3_3_5\vdbeapi.c(55) : warning C4244: 'return' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeapi.c(201) : warning C4244: '=' : conversion from 'double' to 'i64', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeapi.c(238) : warning C4244: '=' : conversion from 'double' to 'u64', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeapi.c(650) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data {linebreak} vdbeaux.c {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(117) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(482) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(527) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(531) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(564) : warning C4018: '<=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(659) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(676) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(862) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(1034) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(1526) : warning C4244: '=' : conversion from 'int' to 'Bool', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(1595) : warning C4244: 'return' : conversion from 'i64' to 'u32', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(1651) : warning C4244: '=' : conversion from 'u64' to 'unsigned char', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(1813) : warning C4018: '>=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(1815) : warning C4018: '>=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(1841) : warning C4018: '<' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(1843) : warning C4018: '<' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(1887) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbeaux.c(1926) : warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data {linebreak} vdbefifo.c {linebreak} vdbemem.c {linebreak} c:\src\sqlite-source-3_3_5\vdbemem.c(49) : warning C4244: 'function' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbemem.c(194) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbemem.c(319) : warning C4244: '=' : conversion from 'double' to 'i64', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbemem.c(491) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbemem.c(557) : warning C4244: '=' : conversion from 'const i64' to 'double', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbemem.c(562) : warning C4244: '=' : conversion from 'const i64' to 'double', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\vdbemem.c(740) : warning C4018: '<=' : signed/unsigned mismatch {linebreak} c:\src\sqlite-source-3_3_5\vdbemem.c(859) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data {linebreak} Generating Code... {linebreak} c:\src\sqlite-source-3_3_5\select.c(3290) : warning C4701: potentially uninitialized local variable 'pTabList' used {linebreak} c:\src\sqlite-source-3_3_5\select.c(3290) : warning C4701: potentially uninitialized local variable 'pEList' used {linebreak} c:\src\sqlite-source-3_3_5\select.c(764) : warning C4701: potentially uninitialized local variable 'pseudoTab' used {linebreak} c:\src\sqlite-source-3_3_5\printf.c(372) : warning C4701: potentially uninitialized local variable 'xtype' used {linebreak} c:\src\sqlite-source-3_3_5\pager.c(1635) : warning C4701: potentially uninitialized local variable 'nameLen' used {linebreak} Compiling... {linebreak} where.c {linebreak} c:\src\sqlite-source-3_3_5\where.c(227) : warning C4244: '=' : conversion from 'int' to 'u8', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(581) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(582) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(583) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(594) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(604) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(605) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(608) : warning C4244: '=' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(630) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(702) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(743) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(744) : warning C4244: '=' : conversion from 'int' to 'i16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(1798) : warning C4244: 'function' : conversion from 'int' to 'u16', possible loss of data {linebreak} c:\src\sqlite-source-3_3_5\where.c(1836) : warning C4244: 'function' : conversion from 'int' to 'u16', possible loss of data {linebreak} Generating Code... {linebreak} Creating library... {linebreak} Build log was saved at "file://c:\src\sqlite-source-3_3_5\Debug\BuildLog.htm" {linebreak} sqlite - 0 error(s), 451 warning(s) {linebreak} ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
#e8e8bd 1785 new active 2006 Apr anonymous Shell 2006 Apr 4 3 rl_readline_name not set Hi, I have a conditionnal construct into my .inputrc: $if sqlite "S ": "select " "L ": "like " "II ": "insert into " "U ": "update " "V ": "view " "(V ": "values (( " "C ": "create " "DR ": "drop " "DI ": "distinct " "F ": "from " "W ": "where " $endif http://tiswww.tis.case.edu/~chet/readline/readline.html#SEC11 but it doesn't work with sqlite because rl_readline_name is not set in the source. I don't know about readline so i can't submit a patch. regards
#e8e8bd 1747 new active 2006 Apr anonymous Unknown 2006 Apr 4 4 Non descriptive error message When operating on closed db handle, sqlite3_exec returns SQLITE_MISUSE, which IMO is quite fair name. But when using: if( rc!=SQLITE_OK ){ fprintf(stderr, "SQL error: (%d) %s\n",rc, zErrMsg); sqlite3_close(db); exit (1); } Message printed is as follows: SQL error: (21) library routine called out of sequence This is a bit misleadig when starting debuging SQLite application.
#f2dcdc 1733 code active 2006 Mar anonymous VDBE 2006 Mar 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
#f2dcdc 1719 code active 2006 Mar anonymous 2006 Mar 4 4 Solaris 8(SQL: bus error while creating temporary file The problem occours since we using gcc 4.0.2 (with gcc 3.4.3 there was no problem). This problem has the same root as Ticket #1584, with the same solution (but only needed for SQLite <= 2.8.17): --- src/os.c.orig 2006-03-17 14:02:53.759531000 +0100 +++ src/os.c 2006-03-17 14:03:18.529535000 +0100 @@ -1652,7 +1652,9 @@ #if OS_UNIX && !defined(SQLITE_TEST) { int pid; - time((time_t*)zBuf); + time_t t; + time(&t); + memcpy(zBuf, &t, sizeof(t)); pid = getpid(); memcpy(&zBuf[sizeof(time_t)], &pid, sizeof(pid)); }
#f2dcdc 1714 code active 2006 Mar anonymous CodeGen 2006 Mar 4 4 Slow query when tables in 2 different files This slow query seems to be sped up by using an explicit CROSS JOIN. ANALYZE apparently does not help. The tables span 2 different database files. Taken from the SQLite mailing list: -- table1.schema (file 1) ATTACH DATABASE './table1.db' AS t1 ; CREATE TABLE t1.table1 ( i_id INT4, b_id INT4, d_id INT4, c_id INT2, data_in REAL, data_out REAL ); CREATE INDEX t1.ix_table1_b_id ON table1( b_id ); DETACH DATABASE t1 ; -- table2.schema (file 2) ATTACH DATABASE './table2.db' AS t2 ; CREATE TABLE t2.table2 ( d_id INT4 PRIMARY KEY, r_id INT2, m_id INT2, i TEXT, ct TEXT, cc TEXT, type TEXT, notes TEXT ); DETACH DATABASE t2 ; -- the slow query (does not use indexes on both tables?) select t1.b_id, t1.c_id, t2.r_id, t2.m_id, sum( t1.data_in ) as data_in, sum( t1.data_out ) as data_out from table1 t1 join table2 t2 on t2.d_id = t1.d_id and t1.b_id >= 100 and t1.b_id < 200 group by t1.b_id, t1.c_id, t2.m_id, t2.r_id; -- the fast query (seems to use both tables' indices) select t1.b_id, t1.c_id, t2.r_id, t2.m_id, sum( t1.data_in ) as data_in, sum( t1.data_out ) as data_out from table1 t1 cross join table2 t2 where t2.d_id = t1.d_id and t1.b_id >= 100 and t1.b_id < 200 group by t1.b_id, t1.c_id, t2.m_id, t2.r_id; More information can be found here: http://www.mail-archive.com/sqlite-users%40sqlite.org/msg13648.html
#e8e8bd 1655 new active 2006 Feb anonymous VDBE 2006 Mar 4 4 Every function can have their private data like agreagates Is it possible to modify the way functions are handled in sqlite ? My idea is to allow functions to have their own private data space to save data from row to row like the agregates have, with that we can have functions that remember last row values, create counters and totalizers that return their updated values for each row. Ex: select increment(1),* from my_table; 1|car|rose|3 2|sea|bike|7 3|flower|water|33 select sum_and_return_row_by_row(row_value_to_sum),* from my_table; 3|car|rose|3 10|sea|bike|7 43|flower|water|33 select current_row_value + last_row_value(current_row_value),* from my_table; 3|car|rose|3 10|sea|bike|7 40|flower|water|33
The structure for that is already there, in fact is the same used by agregates, I was scratching the code but I could not find easily where to introduce code to push the context and pop it for functions that aren't agregates, someone know how to do that ? _2006-Feb-04 20:45:32 by anonymous:_ {linebreak} /* ** Implementation of the increment() function */ static void incrementFunc(sqlite3_context *context, int argc, sqlite3_value **argv){ assert( argc==1 ); switch( sqlite3_value_type(argv[0]) ){ case SQLITE_INTEGER: { i64 iVal = sqlite3_value_int64(argv[0]); i64 *pi = (i64*)&context->s.zShort; *pi = *pi + iVal; sqlite3_result_int64(context, *pi); break; } } }
I've tried that but context are not saved row to row, of course here I was using a hidden member (s.zShort) of the context structure that seems not to be used or damaged, ideally should have a function like "void *sqlite3_set_presistent_data(sqlite3_context *context, void* value, int size_to_be_allocated)" or something like it that will allocate memory and return the actual value stored before if any.
#e8e8bd 1693 new active 2006 Feb anonymous Parser 2006 Mar 4 4 Parser sensitive to position of word AUTOINCREMENT Command: create table unique_ids ( 'id' INTEGER AUTOINCREMENT PRIMARY KEY) fails, while the create table unique_ids ( 'id' INTEGER PRIMARY KEY AUTOINCREMENT) suceeds. The only difference is position of the word AUTOINCREMENT. I originally expected the AUTOINCREMENT to be standalone feature, not tied with PRIMARY KEY. Perhaps the parser may be more forgiving here.
#e8e8bd 1704 new active 2006 Mar anonymous 2006 Mar 4 3 extern "C" block in sqliteInt.h can we put #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } /* End of the 'extern "C"' block */ #endif around the declarations in sqliteInt.h. It would help as we need to access SQLite internals from our C++ code.
#e8e8bd 1683 new active 2006 Feb anonymous Unknown 2006 Feb anonymous 4 3 .mode html produces uppercase tags Quote from one of sqlite docs: "The last output mode is "html". In this mode, sqlite writes the results of the query as an XHTML table. The beginning are not written, but all of the intervening s, s, and | s are. The html output mode is envisioned as being useful for CGI." I tried the ".mode html" and the result is just like the doc said. But there is one oddity. AFAIK, XHTML discourages using uppercase tags. Inspite of that, sqlite produces uppercase tags. Why?? Now, this is a suggestion from a newbie point of view just for the sake of sqlite's consistency: Use lowercase tags for ".mode hmtl" result. I know browsers produce the same result for |
...
as well as for ...
. We all know xhtml 1.0 is just a more strict version of html 4.0 and xhtml is based on xml whilst html 4.o is based on sgml. Not make much any difference to me and the browsers. But following the xhtml standard and rules -that sqlite WANTS- doesn't hurt right? I hope you can consider more seriously this lite suggestion :) Keep up the great work! ps:sorry for my broken english _2006-Feb-21 14:24:54 by anonymous:_ {linebreak} Capitals tags aren't xhtml. {linebreak} Why not offering an export may be also import mode in true xml ? With xsd schema file creation as useful for direct import into spread sheet and other popular programs. {linebreak} Keep on going with this beautiful program.
#e8e8bd 1679 new active 2006 Feb anonymous 2006 Feb 4 4 SQLite requires code modification to replace memory allocation funcs sqliteOsMalloc is a C macro that points to a 'generic' malloc routine by default. The same for realloc and free. This forces a SQLite user to modify the code of each realease to support their own memory functions. Allow it means that the user can no longer use a system wide SQLite library and have to ship their own. If those memory functions where function pointers then the calling program could set them without modifying the source code. These function pointers could be global variables or set by a sqlite_memory_funcs() API function.
#e8e8bd 1663 new active 2006 Feb anonymous Unknown 2006 Feb 4 4 Suggestion: DATETYPE field type using David Tribble's work? How about a new field (/data) type, DATETIME, using David Tribble's excellent proposal? See here: http://david.tribble.com/text/c0xlongtime.html _2006-Feb-09 02:58:34 by drh:_ {linebreak} What advantage does David Tribble's datetype design have over the existing date and time support in SQLite? Why should we change?
#e8e8bd 1653 new active 2006 Feb anonymous CodeGen 2006 Feb 4 5 SQLITE_OMIT_COST_REORDERING ? Embedded SQLite installations could benefit from conditionally compiling out the logic of the cost-based reordering of tables (i.e., always assume cross join). It might save a few kilobytes of code when the join order is always known in advance.
#f2dcdc 1637 code active 2006 Jan anonymous Parser 2006 Jan 4 4 Multiple JOIN USING() doesn't work. CREATE TABLE T1(T1Id, Name); INSERT INTO T1(T1Id, Name) VALUES (0,"titi"); INSERT INTO T1(T1Id, Name) VALUES (1,"toto"); INSERT INTO T1(T1Id, Name) VALUES (2,"tutu"); INSERT INTO T1(T1Id, Name) VALUES (3,"hat"); INSERT INTO T1(T1Id, Name) VALUES (4,"socks"); CREATE TABLE T2(T2Id, Name); INSERT INTO T2(T2Id, Name) VALUES(0,"Black"); INSERT INTO T2(T2Id, Name) VALUES(1,"Red"); INSERT INTO T2(T2Id, Name) VALUES(2,"Blue"); INSERT INTO T2(T2Id, Name) VALUES(3,"Green"); INSERT INTO T2(T2Id, Name) VALUES(4,"Yellow"); INSERT INTO T2(T2Id, Name) VALUES(5,"Brown"); INSERT INTO T2(T2Id, Name) VALUES(6,"White"); CREATE TABLE T3(T3Id,T1Id,T2Id,Number); INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (1,4,0,5); INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (2,4,1,4); INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (3,4,2,3); INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (4,4,3,2); INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (5,4,4,1); INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (6,4,5,0); INSERT INTO T3(T3Id,T1Id,T2Id,Number) VALUES (7,3,0,10); SELECT main.Number AS Number, prod.Name AS product, col.Name AS color, Main.T3Id AS Id FROM T3 AS main LEFT JOIN T1 AS prod USING(T1Id) LEFT JOIN T2 AS col USING(T2Id);
The second USING doesn't work. _2006-Jan-23 16:03:17 by drh:_ {linebreak} SQLite only looks for columns to satisfy the USING clause in the two tables immediately tot he left and right of the join. In the example above, it is trying to resolve "USING(t2id)" by looking for columns t1.t2id and t2.t2id. ---- _2006-Jan-23 23:12:32 by anonymous:_ {linebreak} I'm not sure if you are saying that is the way SQLite should work, or just explaining the source of the error. I believe that JOINS are supposed to combine two tables to produce a third table in a left associative manner. The sample query should join T3 and T1 using T1Id to produce an intermediate table, lets call it simply T. Then T should be joined with T2 using T2Id to produce the final result table. As shown below, T does in fact have a column named T2Id, and this column should be used for the second join. sqlite> CREATE table t AS SELECT * ...> FROM T3 AS main ...> LEFT JOIN T1 AS prod USING(T1Id); sqlite> sqlite> PRAGMA table_info(t); 0|T3Id|numeric|0||0 1|T1Id|numeric|0||0 2|T2Id|numeric|0||0 3|Number|numeric|0||0 4|Name|numeric|0||0 sqlite> sqlite> SELECT T2ID from t; 0 1 2 3 4 5 0 One area where SQLite may have a standards compliance problem is with the name of the result set columns with column name joins (i.e. joins with a USING() clause). The standard says that the result set column that was used to join the two tables can not have a qualifier. That means it is NOT the column from either of the two input tables, and can't be qualified using either table name. The USING clause "projects out" the columns from both of the input tables and replaces them with a single column with the same name. The two columns could have different types for example, and the result set column could be yet another type. The first two otuput columns below should generate an error. Only the third is legal according to the SQL standard. sqlite> SELECT T3.T2Id, T2.T2Id, T2Id from T3 LEFT JOIN T2 USING(T2Id); T2Id|T2Id|T2Id 0|0|0 1|1|1 2|2|2 3|3|3 4|4|4 5|5|5 0|0|0 The type differences between the different columns are displayed in the following example. In one table the values of column a are integers and in the other they are text. The type of the result column depends upon the order of the tables in the join. sqlite> select a from tt1 join tt2 using(a); a 1 2 sqlite> select typeof(a) from tt1 join tt2 using(a); typeof(a) integer integer sqlite> select typeof(a), typeof(tt1.a), typeof(tt2.a) from tt1 join tt2 using(a); typeof(a)|typeof(tt1.a)|typeof(tt2.a) integer|integer|text integer|integer|text sqlite> select * from tt1 join tt2 using(a); a|b|c 1|1|-1 2|4|-2 sqlite> select typeof(a), typeof(tt1.a), typeof(tt2.a) from tt2 join tt1 using(a); typeof(a)|typeof(tt1.a)|typeof(tt2.a) text|integer|text text|integer|text The same rules also apply to NATURAL joins. The result columns cannot legally be qualified by either table name. ---- _2006-Jan-23 23:45:04 by drh:_ {linebreak} My previous remark is describe what SQLite does. You are probably right in pointing out that what it currently does is not correct and ought to be fixed. I merely observet that SQLite has never worked that way and has (up until now) caused no serious concern. So, I'm not going to consider this a high-priority bug. I will get to it as I am able. But I need to get 3.3.x out the door first.
#e8e8bd 1636 todo active 2006 Jan anonymous Shell 2006 Jan drh 4 3 stdev does not work When trying to calculate standard deviation I get the following error message: SQL error: no such function: stdev How does SQLite support statistical function stdev? What is the correct name of the function? The same with sqr and sqrt. What are the names for square and square-root? Is there any other way to use SQLite for statistical calculations?
#e8e8bd 1626 new active 2006 Jan anonymous Unknown 2006 Jan 4 4 ALTER TABLE BUG/MISHEAVIOR I have observed a "bug" in sqlite (3.2.8). when a table is created, and then renamed via the ALTER TABLE statement, the create statement gets adjusted (which is correct), but the new name appears in single quotes. according to sql syntax, table and field names are quoted by double quotes, so this creates subsequent problems for parsing tools and such. to test: create table x(id) select * from sqlite_master (observe the create statememt) alter table x rename to x1 select * from sqlite_master (observe the create statememt again, the name is now 'x1' in quotes) IMHO, the name should not be quoted by default, but only if it contains spaces, special characters and such (in other words, follow the quoting rules for tables that sqlite already has) _2006-Jan-23 00:24:34 by drh:_ {linebreak} The result that SQLite produces is technically correct, even if it fails to meet the aesthetic expectations of this tickets author. Changes SQLite as suggest will make the code base larger, which is something we are loath to do. So I am converting this to a low-priority feature request. ---- _2006-Feb-07 07:36:19 by anonymous:_ {linebreak} ok, lets not do "intelligent" quoting. what about the quote format ? should it not be DOUBLE quotes, instead of single ?
#e8e8bd 1635 doc active 2006 Jan anonymous 2006 Jan 4 4 SQLite Ticket "Version" field The "Version" field in the CVSTrac ticket is ambiguous (particularly for "fixed" bugs). Can it be renamed to "Version Bug Appears" or something to that effect? Also, it would be very useful to see the SQLite version in which the ticket is fixed in addition to the SQLite version which the bug first appears. Manually correlating the date of the fix with the SQLite version is awkward.
#e8e8bd 1627 warn active 2006 Jan anonymous 2006 Jan 4 4 warnings on BCB and how to resolve them + couple of minor fixes I took 3.3.1 sources (the preprocessed version) and tried to compile them on Borland C++ Builder 6.4. I wanted to keep all compiler warnings switched on. I got some warnings from sqlite source. Some due to strlen() returning unsigned, some due signed/unsigned comparison, some because BCB requires if (a = b) ... to be rewritten as if ((a = b) != 0) ... to avoid warnings. List of places generating warnings and ways to shut then up are bellow. Perhaps these fixes may be applied to the codebase since the warnings may happen with other C++ compilers as well. I cannot promise the fixes will work with 64bit architectures but it seems likely. ----------------------------------------- Some macros, like MASTER_NAME, may cause collisions. Perhaps they all can be prefixed with SQLITE3 or so to avoid such accidents. -------------------------------------------- The trick to enable NDEBUG in sqliteInt.h: #if !defined(NDEBUG) && !defined(SQLITE_DEBUG) # define NDEBUG 1 #endif has unfortunate property of changing NDEBUG settings in those parts of a project using sqlite and not in the others. It is hard to detect reason for possible problems. I suggest: 1) Put on top of each sqlite source file #define THIS_IS_SQLITE_SOURCE 2) Change the trick to: #if !defined(NDEBUG) && !defined(SQLITE_DEBUG) && (defined THIS_IS_SQLITE_SOURCE) # define NDEBUG 1 #endif -------------------------------------------- Small wish for the documentation: could there be information how to switch off all sqlite memory management and checking and leave it all to host's malloc/realloc/free? I have very optimized dmalloc allocator and want to be sure there are no other layers above this. My allocator also does boundary checking and error detection. -------------------------------------------- ---- FIXES TO GET RID OF WARNINGS ON BCB --- -------------------------------------------- vdbmem.c, line 725: assert( strlen(pMem->z)<=pMem->n ); ==>> assert( (int)strlen(pMem->z)<=pMem->n ); -------------------------------------------- vdbeaux.c: line 545: if( strlen(zTemp)+strlen(zNum)+1<=nTemp ){ ==>> if( (int)strlen(zTemp)+(int)strlen(zNum)+1<=nTemp ){ line 1740: if( d1>=nKey1 && sqlite3VdbeSerialTypeLen(serial_type1)>0 ) break; ==>> if( (int)d1>=nKey1 && sqlite3VdbeSerialTypeLen(serial_type1)>0 ) break; line 1742: if( d2>=nKey2 && sqlite3VdbeSerialTypeLen(serial_type2)>0 ) break; ==>> if( (int)d2>=nKey2 && sqlite3VdbeSerialTypeLen(serial_type2)>0 ) break; line 1768: }else if( d1> }else if( (int)d1> }else if( (int)d2hdrOffset+3]) ); ==>> assert( iCell<(int)get2byte(&data[pPage->hdrOffset+3]) ); line 932: if( nPayload<=pPage->maxLocal ){ ==>> if( (int)nPayload<=pPage->maxLocal ){ line 1150: assert( nCell==get2byte(&data[hdr+3]) ); ==>> assert( nCell==(int)get2byte(&data[hdr+3]) ); line 2351: if( origSize>=PENDING_BYTE_PAGE(pBt) && finSize<=PENDING_BYTE_PAGE(pBt) ){ ==>> if( (int)origSize>=PENDING_BYTE_PAGE(pBt) && (int)finSize<=PENDING_BYTE_PAGE(pBt) ){ line 2367: if( PTRMAP_ISPAGE(pgsz, iDbPage) || iDbPage==PENDING_BYTE_PAGE(pBt) ){ ==>> if( PTRMAP_ISPAGE(pgsz, iDbPage) || (int)iDbPage==PENDING_BYTE_PAGE(pBt) ){ line 2916: if( offset+amt > nKey+pCur->info.nData ){ ==>> if( offset+amt > (int)(nKey+pCur->info.nData) ){ line 3056: if( nLocal>nKey ){ ==>> if( nLocal>(int)nKey ){ line 3737: if( *pPgno>sqlite3pager_pagecount(pBt->pPager) ){ ==> if( *pPgno>(Pgno)sqlite3pager_pagecount(pBt->pPager) ){ line 3774: assert( *pPgno!=PENDING_BYTE_PAGE(pBt) ); ==>> assert( *pPgno!=(Pgno)PENDING_BYTE_PAGE(pBt) ); line 3779: assert( *pPgno!=PENDING_BYTE_PAGE(pBt) ); ==>> assert( *pPgno!=(Pgno)PENDING_BYTE_PAGE(pBt) ); line 3789: assert( *pPgno!=PENDING_BYTE_PAGE(pBt) ); ==>> assert( *pPgno!=(Pgno)PENDING_BYTE_PAGE(pBt) ); line 3879: if( ovflPgno>sqlite3pager_pagecount(pBt->pPager) ){ ==>> if( ovflPgno>(Pgno)sqlite3pager_pagecount(pBt->pPager) ){ line 3774: assert( *pPgno!=PENDING_BYTE_PAGE(pBt) ); ==>> assert( *pPgno!=(Pgno)PENDING_BYTE_PAGE(pBt) ); line 3938: assert( info.nData==nData ); ==>> assert( (int)info.nData==nData ); line 4166: assert( end <= get2byte(&data[hdr+5]) ); ==>> assert( end <= (int)get2byte(&data[hdr+5]) ); line 4972: assert( pgnoChild<=sqlite3pager_pagecount(pPage->pBt->pPager) ); ==>> assert( pgnoChild<=(Pgno)sqlite3pager_pagecount(pPage->pBt->pPager) ); line 5399: pgnoRoot==PENDING_BYTE_PAGE(pBt) ){ ==>> pgnoRoot==(Pgno)PENDING_BYTE_PAGE(pBt) ){ line 5491: if( pgno>sqlite3pager_pagecount(pBt->pPager) ){ ==>> if( pgno>(Pgno)sqlite3pager_pagecount(pBt->pPager) ){ line 5616: if( iTable==maxRootPgno ){ ==>> if( iTable==(int)maxRootPgno ){ line 5659: if( maxRootPgno==PENDING_BYTE_PAGE(pBt) ){ ==>> if( maxRootPgno==(Pgno)PENDING_BYTE_PAGE(pBt) ){ line 5665: assert( maxRootPgno!=PENDING_BYTE_PAGE(pBt) ); ==>> assert( maxRootPgno!=(Pgno)PENDING_BYTE_PAGE(pBt) ); if( (rc = restoreOrClearCursorPosition(pCur, 1)) || (rc = saveAllCursors(pBt, pCur->pgnoRoot, pCur)) || (rc = sqlite3pager_write(pPage->aData)) ){ ==>> if( (rc = restoreOrClearCursorPosition(pCur, 1)) != 0 || (rc = saveAllCursors(pBt, pCur->pgnoRoot, pCur)) != 0|| (rc = sqlite3pager_write(pPage->aData)) != 0 ){ (to get rid "possibly incorrect assigment" warning) line 3353: int dummy; pCell += getVarint32(pCell, &dummy); ==>> u32 dummy; pCell += getVarint32(pCell, &dummy); line 3342: i64 nCellKey; ==>> u64 nCellKey; because it causes warning in line 3353 in getVarint(pCell, &nCellKey); -------------------------------------------- build.c: line 622: if( (!OMIT_TEMPDB || i!=1 ) && n==strlen(pDb->zName) && ==>> if( (!OMIT_TEMPDB || i!=1 ) && n==(int)strlen(pDb->zName) && line 2367: pIndex->aiRowEst = (int *)(&pIndex->aiColumn[nCol]); ==>> pIndex->aiRowEst = (unsigned *)(&pIndex->aiColumn[nCol]); (the type is defined as unsigned in sqliteInt.h) -------------------------------------------- vdbe.c: line 1967: assert( p2> assert( p2<(int)nField ); line 1967: if( avail>=payloadSize ){ ==>> if( avail>=(int)payloadSize ){ line 2019: if( !zRec && avail> if( !zRec && avail<(int)offset ){ line 2034: for(i=0; i> for(i=0; i<(int)nField; i++){ -------------------------------------------- select.c, line 113: if( p->n==keywords[j].nChar ==>> if( (int)(p->n)==keywords[j].nChar -------------------------------------------- expr.c, line 350: && pE->token.n==n ==>> && (int)(pE->token.n)==n -------------------------------------------- shell.c: functions isatty() and access() are in on Borland. I suggest to add: #if (defined __BORLANDC__) # include #endif and at the same time to comment out shell.c, line 59: #if !(defined __BORLANDC__) extern int isatty(); #endif Prototype on BCB is int isatty(int handle); -------------------------------------------- pager.c: line 600: for(i=0; i> for(i=0; i<(int)len; i++){ line 1016: if( pgno==0 || pgno==PAGER_MJ_PGNO(pPager) ){ ==>> if( pgno==0 || pgno==(Pgno)PAGER_MJ_PGNO(pPager) ){ line 1341: assert( pPager->origDbSize==0 || pPager->origDbSize==mxPg ); ==>> assert( pPager->origDbSize==0 || (Pgno)(pPager->origDbSize)==mxPg ); line 1354: for(i=0; i> for(i=0; i<(int)nRec; i++){ line 1935: if( pPg->pgno<=dbSize ){ ==>> if( pPg->pgno<=(Pgno)dbSize ){ line 2308: if( pList->pgno<=pPager->dbSize ){ ==>> if( pList->pgno<=(Pgno)(pPager->dbSize) ){ line 2560: if( pgno>PAGER_MAX_PGNO || pgno==0 || pgno==PAGER_MJ_PGNO(pPager) ){ ==>> if( pgno>PAGER_MAX_PGNO || pgno==0 || pgno==(Pgno)PAGER_MJ_PGNO(pPager) ){ line 3043: assert( pPg->pgno!=PAGER_MJ_PGNO(pPager) ); ==>> assert( pPg->pgno!=(Pgno)PAGER_MJ_PGNO(pPager) ); line 3672: for( i=nTrunc+1; i<=pPager->origDbSize; i++ ){ ==>> for( i=nTrunc+1; i<=(Pgno)(pPager->origDbSize); i++ ){ line 3673: if( !(pPager->aInJournal[i/8] & (1<<(i&7))) && i!=iSkip ){ ==>> if( !(pPager->aInJournal[i/8] & (1<<(i&7))) && i!=(Pgno)iSkip ){ -------------------------------------------- printf.c, line 409: *(--bufpt) = cset[longvalue%base]; ==>> *(--bufpt) = cset[(unsigned)(longvalue%base)]; Here BCB complains on using 64 bit integer as array index with warning "suspcious pointer conversion". -------------------------------------------- Lot of code complains on memory debug functions not compiled in but used within asserts: util.c: line 1360: assert( sqlite3ThreadData()->mallocDisallowed>=0 ); sqlite3ThreadData()->mallocDisallowed++; ==>> #ifdef SQLITE_MEMDEBUG assert( sqlite3ThreadData()->mallocDisallowed>=0 ); sqlite3ThreadData()->mallocDisallowed++; #endif line 1369: assert( sqlite3ThreadData()->mallocDisallowed>0 ); sqlite3ThreadData()->mallocDisallowed--; ==>> #ifdef SQLITE_MEMDEBUG assert( sqlite3ThreadData()->mallocDisallowed>0 ); sqlite3ThreadData()->mallocDisallowed--; #endif line 556: while( !(p = OSMALLOC(n)) && sqlite3_release_memory(n) ); ==>> while( (p = OSMALLOC(n))==0 && sqlite3_release_memory(n) ); This is officially BCB recommended trick to shut up "possibly incorrect assignement" message. The docs says: if (a = b) ... should be rewritten as if ((a = b) != 0) ... line 586: while( !(np = OSREALLOC(p, n)) && sqlite3_release_memory(n) ); ==>> while( (np = OSREALLOC(p, n))==0 && sqlite3_release_memory(n) ); line 739: if( db && (db->pErr || (db->pErr = sqlite3ValueNew()))!=0 ){ ==>> if( db && (db->pErr || ((db->pErr = sqlite3ValueNew())!=0))!=0 ){ -------------------------------------------- There are several more warnings when BCB compiler claims a function has no prototype where it has. It is knon Borland bug and the only way to fix it is to add #ifdef __BORLANDC__ # pragma -warn ... #endif ...statements... #ifdef __BORLANDC__ # pragma .warn ... #endif inside sqlite code. I do not know whether you wish to pollute the code with such specific workarounds. If yes, I may provide more details. EOF
#e8e8bd 1588 new active 2006 Jan anonymous 2006 Jan 4 4 common subexpression elimination not performed in SELECT SQLite could perform common subexpression elimination to significantly speed up certain SELECT statements. Consider the following: CREATE TABLE t6(a); INSERT INTO "t6" VALUES(1); INSERT INTO "t6" VALUES(2); -- ...imagine 5000 more rows inserted... INSERT INTO "t6" VALUES(4999); INSERT INTO "t6" VALUES(5000); CREATE VIEW v6 as SELECT x.a as xa, y.a as yb, (123.45*x.a*y.a-x.a*x.a) AS expr FROM t6 x, t6 y; With the following SELECT statement: explain select expr s1, (expr/789.3) s2 from v6 order by s1; You can see that SQLite repeats the calculation of 'expr' three times below. If the common subexpression 'expr' was calculated just once per inner-loop iteration this query would be significantly faster. 0|OpenVirtual|3|3|keyinfo(1,BINARY) 1|Goto|0|58| 2|Integer|0|0| 3|OpenRead|1|2| 4|SetNumColumns|1|1| 5|Integer|0|0| 6|OpenRead|2|2| 7|SetNumColumns|2|1| 8|Rewind|1|46| 9|Rewind|2|45| -- first expr 10|Real|0|0|123.45 11|Column|1|0| 12|Multiply|0|0| 13|Column|2|0| 14|Multiply|0|0| 15|Column|1|0| 16|Column|1|0| 17|Multiply|0|0| 18|Subtract|0|0| -- second expr 19|Real|0|0|123.45 20|Column|1|0| 21|Multiply|0|0| 22|Column|2|0| 23|Multiply|0|0| 24|Column|1|0| 25|Column|1|0| 26|Multiply|0|0| 27|Subtract|0|0| 28|Real|0|0|789.3 29|Divide|0|0| 30|MakeRecord|2|0| -- third expr 31|Real|0|0|123.45 32|Column|1|0| 33|Multiply|0|0| 34|Column|2|0| 35|Multiply|0|0| 36|Column|1|0| 37|Column|1|0| 38|Multiply|0|0| 39|Subtract|0|0| 40|Sequence|3|0| 41|Pull|2|0| 42|MakeRecord|3|0| 43|IdxInsert|3|0| 44|Next|2|10| 45|Next|1|9| 46|Close|1|0| 47|Close|2|0| 48|Sort|3|57| 49|Column|3|2| 50|Integer|2|0| 51|Pull|1|0| 52|Column|-1|0| 53|Column|-2|1| 54|Callback|2|0| 55|Pop|2|0| 56|Next|3|49| 57|Halt|0|0| 58|Transaction|0|0| 59|VerifyCookie|0|2| 60|Goto|0|2| 61|Noop|0|0| The common sub-expression elimination may have to take into account user-defined functions that do not return the same value when given the same inputs (such as random()). Some databases fold such values into a single expression, while others evaluate each such function in a seperate expression. _2006-Jan-08 18:55:03 by drh:_ {linebreak} Common Subexpression Eliminationi (CSE) is a planned enhancement to occur after the VDBE is converted from a 3-operand stack machine to a 4-operand register machine. Perhaps this year sometime. ---- _2006-Jan-08 19:56:47 by anonymous:_ {linebreak} I think it would be desirable to have a seperate expression optimization pass before (and without knowledge of) the VDBE code generation phase to simplify and optimize the SQL abstract syntax tree. Such high level AST transformation appears to already happen in select.c in such routines as flattenSubquery(), but it would be great if all non-VDBE-specific expression tree manipulation code could be factored out into seperate .c files so that it would be completely independent of the code generation. This could allow you support a variety of backends.
#e8e8bd 1576 build active 2005 Dec anonymous 2005 Dec 4 4 PREFIX is not honored (cannot install as non-root) Hi, sqliters! A minor install problem in 3.2.7: the tree cannot be installed as non-root because it does not completely honor the configure prefix. e.g.: ./configure --prefix=$HOME ... make install tclsh ./tclinstaller.tcl 3.2 can't create directory "/usr/lib/tcl8.4/sqlite3": permission denied while executing "file mkdir $LIBDIR/sqlite3" (file "./tclinstaller.tcl" line 15) However, /usr/lib should presumably be $HOME/lib when --prefix=$HOME. Doing the install as root works but of course copies most of the files under $HOME but owned by root (which of course isn't the desired behaviour). Take care, This is a dupe of 1549.
#e8e8bd 1565 doc active 2005 Dec anonymous 2005 Dec 4 4 wrong return-type specified for sqlite3_db_handle in c-api-reference The c-api-documentation tells, that sqlite3_db_handle returns an int. This is not true. It returns the databasehandle as sqlite3*. The line in capi3ref: int sqlite3_db_handle(sqlite3_stmt*); should be replaced by sqlite* sqlite3_db_handle(sqlite3_stmt*);
#e8e8bd 1564 build active 2005 Dec anonymous 2005 Dec 4 4 Need GNU awk The autotools (esp. automake) need to be sure to use GNU awk. I attempted to build sqlite on the following system: SunOS apache 5.10 Generic_118822-23 sun4u sparc SUNW,Sun-Fire-880 On this the system `which awk` is not a GNU awk. The build proceeds as follows (up to the first error): ==== sed -e s/--VERS--/3.2.7/ ./src/sqlite.h.in | \ sed -e s/--VERSION-NUMBER--/3002007/ >sqlite3.h gcc -g -O2 -o lemon ./tool/lemon.c cp ./tool/lempar.c . cp ./src/parse.y . ./lemon -DSQLITE_OMIT_CURSOR parse.y cat parse.h ./src/vdbe.c | awk -f ./mkopcodeh.awk >opcodes.h awk: syntax error near line 36 ==== Apparently this syntax is not available in the standard awk on this system. Making `which awk` point to a GNU awk resolves the issue. Possible solutions: 0. Replace all instances of awk with gawk in the scripts 1. Use Autotools to request/use gawk instead of awk (maybe a hints file?) Brady
#e8e8bd 1532 new active 2005 Nov anonymous TclLib 2005 Nov 4 4 Variables don't get replaced in ATTACH statements. When using mydb eval {ATTACH $var as var} in tcl scripts, $var is not replaced by its corresponding value. proc updatedb { filename } { sqlite3 mem :memory: ... mem eval {ATTACH $filename as file} mem eval {REPLACE INTO file.table SELECT * FROM table} mem close } Will result in the errormessage: "No such table file.table" (additionally a file called $filename will be created in the current dir). But if you quote the ATTACH statement and let TCL handle the replacement it will work just fine. This behavior is exactly as defined in the documentation. Variable substitution is only allowed in places where it is valid to put an expression. There are important technical reasons for this restriction. Works as designed. ----- On second thought, I suppose it would be possible to extend the parser so that it allowed a (string value) expression at the point in the ATTACH command where a filename is needed. I will change this into an enhancment request.
#f2dcdc 1515 code active 2005 Nov anonymous Unknown 2005 Nov 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.
#f2dcdc 1500 code active 2005 Oct anonymous Unknown 2005 Oct 4 4 MIssing file listing permission causes DB opening/creation to fail When using SQLite in PHP 5.0.5, trying to create or open a SQLite database in a directory to which the path does not have file listing (r) permissions all the way, the opening or creation fails. Please see PHP bug report #34868: http://bugs.php.net/bug.php?id=34868
The PHP developers say that this is phenomenon is caused by the SQLite code, and suggested that I should forward this to you for possible investigation, as they merely bundle the lib with their PHP releases (and have some kind of minimal wrapper around it). It is worth noting that this problem seem to appear in other PHP situations as well (then mostly connected to the usage of PHP's "Safe Mode" or "open_basedir" restrictions), but should appear with just about any application using getcwd() under IBM AIX. The underlying reason is that getcwd() under IBM AIX fails if file listing (r) permissions are missing somewhere along the path. However, I am not sure if there are other, equal, means of determining the current working directory without using getcwd(). Best regards, Bjorn Wiberg
#e8e8bd 1498 build active 2005 Oct anonymous 2005 Oct 4 3 SQLite Cygwin support I'm attaching a patch to Makefile.in to support building sqlite3 on Cygwin, as well as the results of make test from 3.2.7. Binary packages are available at: ftp://sunsite.dk/projects/cygwinports/release/sqlite3/
#e8e8bd 1491 new active 2005 Oct anonymous Shell 2005 Oct 4 4 syntax error with " .mode column: when I key in ".mode column" without any space, the command is work well. If I key in "^.mode column" with a space(the ^ means a space) , it will show the following error message : ===================================================== SQL error: near "syntax": syntax error ===================================================== Would you like fix it on next version, please ? Have a nice day! John Wei
#f2dcdc 1484 code active 2005 Oct anonymous Unknown 2005 Oct 4 4 Solaris8 awk problem /usr/bin/awk in Solaris8 doesn't have sub() function. To avoid this problem, use @AWK@ in Makefile and add AC_PROG_AWK in configure.ac.
#f2dcdc 1298 code active 2005 Jun anonymous Shell 2005 Oct drh 4 3 sqlite3.exe not recognizing newline as comment terminator The sqlite3.exe program does not recognize comments that end in a newline if there is valid SQL before them on the same line. The statement: {linebreak} "SELECT 1; -- this is a comment" {linebreak} should be valid SQL, but sqlite3.exe still requires a semicolon after the comment. Please look at the test below: C:\Temp\SQLite>sqlite3 SQLite version 3.2.1 Enter ".help" for instructions sqlite> select 1; 1 sqlite> select 1; -- test comment ...> ; 1 sqlite> select 1; -- test; 1 sqlite> _2005-Jun-22 18:20:37 by anonymous:_ {linebreak} The string "SELECT 1; -- this is a comment" is not valid SQL. SQL does not use the semicolon character inside SQL statements except to seperate the constituent statements of a trigger, stored procedure, or an embedded program. The semicolon is used by sqlite3.exe (and standard SQL) as a end of statement marker that triggers it to parse and execute the input up to that point. From the SQL 2003 standard: 21 Direct invocation of SQL 21.1 Function Specify direct execution of SQL. Format ::= This SQL statement should be "SELECT 1 --this is a comment" followed by a semicolon to mark the end of the statement. Putting the semicolon in the middle terminates the first statement at that point, executes it, and then starts collecting input for a second statement (which in this case does not have a terminating semicolon). Note that sqlite3 also accepts the word GO (used by SQL server) or the Oracle compatible character "/" as the end of statement marker, but only when they appear on a line of input by themselves (i.e. at the continuation prompt in the shell). sqlite> SELECT 1 --this is a comment ...> go 1 sqlite> SELECT 1 --this is a comment ...> / 1 sqlite>
#e8e8bd 1464 new active 2005 Oct anonymous 2005 Oct 4 3 Improving PRAGMA table_info() I have a small feature request regarding PRAGMA table_info() to add a new column named "auto_inc" which contains 1 if the corresponding field has the AUTO INCREMENT in its definition and 0 otherwise. _2005-Oct-04 15:37:31 by anonymous:_ {linebreak} Once suggestions for extending the PRAGMA table_info() are on the agenda, I would like to suggest that the COLLATION sequence used for an INDEX would be made available as well.
#e8e8bd 1454 doc active 2005 Sep anonymous 2005 Sep 4 4 Functions should all be documented in one place Currently some, but not all, of SQLite's functions are documented in lang_expr.html. For example, the date/time functions are only documented in a wiki page that describes them as "experimental." It would be nice if they could be moved into the "official" documentation.
#f2dcdc 1451 code active 2005 Sep anonymous Shell 2005 Sep 4 3 .mode insert does not output BLOBs in an usable way sqlite> CREATE TABLE a(b); sqlite> INSERT INTO a VALUES (X'41424300500051'); sqlite> .dump BEGIN TRANSACTION; CREATE TABLE a(b); INSERT INTO "a" VALUES(X'41424300500051'); COMMIT; sqlite> .mode insert sqlite> SELECT * FROM a; INSERT INTO table VALUES('ABC');
It would be nice for ".mode insert" to print a command that would actually re-create the same data, the same as ".dump" (the obvious difference is that .dump can't filter data in any way, it just dumps it all) or, at least, it would be very nice if the already existing function that "prints binary data as X'-encoded-string" were reachable from SQL, so that one could use something like: SELECT xencode(b) FROM a;
and obtain X'41424300500051'
_2005-Sep-25 17:03:40 by anonymous:_ {linebreak} I am not the original ticket poster, but I noticed that this feature request is related to {link: http://lists.gnu.org/archive/html/monotone-devel/2005-09/msg00294.html Monotone} migrating away from Base64 encoding to using straight Sqlite blobs. ---- _2005-Sep-26 01:49:33 by drh:_ {linebreak} The built-in quote() function converts BLOBs into ascii BLOB literals. Will it not server for the requested xencode() function? SELECT quote(b) FROM a ---- _2005-Sep-26 08:57:47 by anonymous:_ {linebreak} Yes, I guess it can perfectly do. What about ".mode insert" output? Is it supposed to print raw data?
#f2dcdc 1441 code active 2005 Sep anonymous VDBE 2005 Sep 4 4 sqlite3_clear_bindings routine missing Implementation of sqlite3_clear_bindings routine is missing. I fix it this way, but the question is if that is correct... in vdbeapi.c :
/* ** The following routine unbind (set to NULL) binded parameters */ int sqlite3_clear_bindings(sqlite3_stmt *pStmt){ Vdbe *p = (Vdbe*)pStmt; int i; for(i = 1; i <= p->nVar; i++) vdbeUnbind(p, i); return SQLITE_OK; }
_2005-Sep-19 10:06:12 by anonymous:_ {linebreak} The function is in experimental.c. check the source file.
#e8e8bd 1427 build active 2005 Sep anonymous 2005 Sep 4 3 tclsqlite.lo target should define USE_TCL_STUBS The Tcl_InitStubs routine is not called in Sqlite3_Init because USE_TCL_STUBS is never defined in the generated Makefile. It appears that the tclsqlite.lo target is the one used in the TCL extension shared library and therefore this target should have -DUSE_TCL_STUBS defined. Below is a diff showing the changes I made to make this work properly in my environment. There also appears to be some type of abortive effort to do this with the tclsqlite-stubs.lo target, but this target is never referenced in the Makefile and erroneously defines TCL_USE_STUBS rather than USE_TCL_STUBS. cvs diff Makefile.in Index: Makefile.in =================================================================== RCS file: /sqlite/sqlite/Makefile.in,v retrieving revision 1.134 diff -r1.134 Makefile.in 369c369 < $(LTCOMPILE) -c $(TOP)/src/tclsqlite.c --- > $(LTCOMPILE) -DUSE_TCL_STUBS -c $(TOP)/src/tclsqlite.c _2005-Sep-19 21:05:50 by anonymous:_ {linebreak} I was just going to report this Makefile bug and I see this reported a few days ago. I think that the correct fix is two-fold: use the correct -DUSE_TCL_STUBS=1 when building tclsqlite-stubs.lo, and then actually _use_ tclsqlite-stubs.lo when building libtclsqlite3.la. While the stub-version of tclsqlite.lo may work when linked into sqlite3_analyzer and the test drivers, it is not the proper way to do things. The patch for Makefile.in that _I_ used is appended. Dave Bodenstab dave@bodenstab.org --- Makefile.in 2005/09/17 23:28:06 32.6 +++ Makefile.in 2005/09/19 20:18:51 @@ -235,8 +235,8 @@ $(LTLINK) -o libsqlite3.la $(LIBOBJ) $(LIBPTHREAD) \ ${ALLOWRELEASE} -rpath $(libdir) -version-info "8:6:8" -libtclsqlite3.la: tclsqlite.lo libsqlite3.la - $(LTLINK) -o libtclsqlite3.la tclsqlite.lo \ +libtclsqlite3.la: tclsqlite-stubs.lo libsqlite3.la + $(LTLINK) -o libtclsqlite3.la tclsqlite-stubs.lo \ $(LIBOBJ) @TCL_STUB_LIB_SPEC@ $(LIBPTHREAD) \ -rpath $(libdir)/sqlite \ -version-info "8:6:8" @@ -412,7 +412,7 @@ $(LTCOMPILE) -DTCLSH=1 -o $@ -c $(TOP)/src/tclsqlite.c tclsqlite-stubs.lo: $(TOP)/src/tclsqlite.c $(HDR) - $(LTCOMPILE) -DTCL_USE_STUBS=1 -o $@ -c $(TOP)/src/tclsqlite.c + $(LTCOMPILE) -DUSE_TCL_STUBS=1 -o $@ -c $(TOP)/src/tclsqlite.c tclsqlite3: tclsqlite-shell.lo libsqlite3.la $(LTLINK) -o tclsqlite3 tclsqlite-shell.lo \ ---- _2005-Sep-19 21:09:14 by drh:_ {linebreak} I think that if you want to build a shared library for use with TCL, you ought to use the TEA-compatible tarball that is found on the website, not the standard source delivery. The Makefile in the TEA-compatible tarball is much, much more likely to work correctly.
#f2dcdc 1403 code active 2005 Sep anonymous Pager 2005 Sep 4 4 Newly initialized pages aren't completely cleared Rational Purify reports many, many UMRs within SQLite, all originating from the following code path: sqlite3OsWrite [os_win.c:296]{linebreak} pager_write_pagelist [pager.c:2209]{linebreak} sqlite3pager_get [pager.c:2445]{linebreak} getPage [btree.c:1114]{linebreak} allocatePage [btree.c:3153]{linebreak} At a glance, it appears that the problem lies in sqlite3pager_get, which does appear to fully clear the newly allocated page. A portion of the Purify-generated backtrace is attached. _2005-Sep-01 15:41:50 by drh:_ {linebreak} SQLite does not clear "don't-care" sections of the page. Doing so would use CPU cycles unnecessarily and hence slow things down. That unused sections of a database page are never initialized is a feature of SQLite, not a bug. ---- _2005-Sep-01 16:17:17 by anonymous:_ {linebreak} Would it be possible to clear the entire page when NDEBUG is not defined? Admittedly, not clearing the page has no ill effects; it does clutter the output from Purify quite a bit though, which will inevitably lead to missing a real error amidst the noise. ---- _2005-Sep-01 17:59:04 by anonymous:_ {linebreak} Actually, it looks like I was off the mark as to what's causing this. It isn't writing a newly allocated page that's causing the warning, but reuse of an existing page (from pPager->pFirstSynced). So I'm not sure what needs to be cleared to avoid the warning; some range within the page's memory area, obviously, but it's not as simple as just memset'ing the entire memory area like it would be when the page is freshly allocated earlier in sqlite3pager_get.
#f2dcdc 1401 code active 2005 Aug anonymous Shell 2005 Aug 4 4 concatenating html in select list create table test( f1 text, f2 text ); insert into table values( 'hello', 'world' ); .mode html select f1 || '
' || f2 from test; hello<br>world |
Of course, I would like to see hello world |
#e8e8bd 1393 event active 2005 Aug anonymous Unknown 2005 Aug 4 3 failure in select2-2.0.3... test The "select2-2.0.3" self-test of sqlite 3.2.5 self test returned a bogus result, quote (indented by 2 spaces each): select2-2.0.1... Ok time with cache: 4123975 microseconds per iteration select2-2.0.2... Ok time without cache: 3089313 microseconds per iteration select2-2.0.3... Expected: [1] Got: [0] select2-2.1... Ok [...] 1 errors out of 20174 tests Failures on these tests: select2-2.0.3 This was on SuSE Linux 9.3 (kernel 2.6.11.4-21.8-default, a SUSE modified kernel) on a ext3 file system with 850 MB free on a parallel ATA hard disk drive with UDMA (i. e. CRC checking). The configure options were: ../configure -C CFLAGS="-O2 -march=i586 -mcpu=athlon-xp" The compiler was: gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) I haven't yet had the time to re-run the test with a released GCC 3.3.X or 3.4.Y compiler, but can do so if that is desired. Please send directions how to run only this test or a smaller subset of the tests. _2005-Aug-29 02:08:53 by anonymous:_ {linebreak} This doesn't look like a major failure. The test is timing related. Did you run "make test" on an otherwise idle machine, or did you have other cpu/disk intensive processes running? For comparison (using kernel-2.4.31, glibc-2.3.5, and gcc-3.3.6): # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(tm) XP 2200+ ... # ./testfixture test/select2.test select2-1.1... Ok select2-1.2... Ok select2-2.0.1... Ok time with cache: 447501 microseconds per iteration select2-2.0.2... Ok time without cache: 1255564 microseconds per iteration select2-2.0.3... Ok ... 0 errors out of 21 tests Failures on these tests: ---- _2005-Aug-29 23:21:08 by drh:_ {linebreak} To run the "select2" set of tests, do this: ./testfixture ../sqlite/test/select2.test ---- _2005-Aug-29 23:25:12 by drh:_ {linebreak} I'm running SuSE 9.2 with an 3.0GHz P4. My test times are *much* faster: select2-2.0.1... Ok time with cache: 767370 microseconds per iteration select2-2.0.2... Ok time without cache: 1879281 microseconds per iteration Since the test time should be dominated by disk I/O not CPU, I am not sure why this is. Are you running on a laptop?
#e8e8bd 1313 new active 2005 Jun anonymous 2005 Jun 4 4 Allow headers in imported text files Please enhance the '.import' command to add a switch which allows the user to specify whether or not the imported text file contains headers. If it does, they can be silently discarded. As it stands the header row will be imported as a normal data row. _2007-Jan-26 16:57:48 by anonymous:_ {linebreak} This feature would be very nice, but it would also be great to be able to create a table using the header row as column names during .import.
#f2dcdc 1286 code active 2005 Jun anonymous 2005 Jun 4 4 The downloadable DLL file does not work with Intel VTune The DLL which can be downloaded in sqlitedll-3_2_2.zip does not work with the Intel VTune profiler version 7.2. I don't know the cause of the problem, but after recreating the DLL with Visual Studio 2003 from the source found in sqlite-source-3_2_2.zip, it works well.
#f2dcdc 1255 code active 2005 May anonymous 2005 May 4 3 Decrease number of warnings with Microsoft Visual C++ Add this to sqliteInt.h to decrease the number of warnings produced by sqlite: #if defined(_MSC_VER) #pragma warning (disable: 4018) // signed/unsigned mismatch #pragma warning (disable: 4244) // conversion from 'unsigned __int64 ' to 'unsigned char ', possible loss of data #pragma warning (disable: 4761) // integral size mismatch in argument; conversion supplied #endif _2005-May-20 19:27:50 by drh:_ {linebreak} Is there no command-line option on microsoft to disable these warnings? ---- _2005-May-21 08:56:15 by anonymous:_ {linebreak} It's possible to lower the warning level, from say 3 to 2 using the command line. But this is not as selective and will remove more warnings than those #pragmas.
#e8e8bd 1246 warn active 2005 May anonymous 2005 May 4 3 Many warnings from gcc4 Compiling 3.2.0 on Fedora Core 4 Test 3 with gcc 4 gives MANY: 'pointer targets in assignment differ in signedness' warnings
#f2dcdc 1241 code active 2005 May anonymous 2005 May 4 5 sqlite3_create_collation16 - should have 'const void* zName' arg sqlite3_create_collation16 - should have 'const void* zName' arg NOT 'const char* zName' I believe that: int sqlite3_create_collation16( sqlite3*, const char *zName, int eTextRep, void*, int(*xCompare)(void*,int,const void*,int,const void*) ); in sqlite3.h should be: int sqlite3_create_collation16( sqlite3*, const void *zName, /* <<== CHANGE HERE <<== */ int eTextRep, void*, int(*xCompare)(void*,int,const void*,int,const void*) );
#f2dcdc 1235 code active 2005 May anonymous Unknown 2005 May drh 4 3 inconsistent pragma handling The pragma user_version and schema_version are handled inconsistently in this respect : the result set returned contains a single column that has no name. all other pragmas return named columns. since some high-level languages complain about db fields with no names (most wrappers will gag at this), I suggest that a simulated "column_name" is also generated here, as with all other pragmas.
#f2dcdc 1228 code active 2005 Apr anonymous Unknown 2005 Apr 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
#e8e8bd 1220 new active 2005 Apr anonymous 2005 Apr 4 3 Selectable calling convention It would be helpful to be able to specify the calling convention for the SQLite API functions when building the library. This is sometimes an issue when writing wrapper libraries, specifically for .NET, which assumes a stdcall calling convention when calling DLL's. The default cdecl calling convention of a C DLL such as SQLite causes a bit of unnecessary overhead for the .NET runtime. This is accomplished with Visual C++ (and GCC is similar) by adding a modifier to a function declaration... void __stdcall sqlite3_open (); This can be implemented using a macro, so the library can be compiled with the desired calling convention... void SQLITE_CALL sqlite3_open (); In sqlite3.h, the default macro would be empty... #ifndef SQLITE_CALL {linebreak} #define SQLITE_CALL {linebreak} #endif
#e8e8bd 1208 new active 2005 Apr anonymous Unknown 2005 Apr 4 4 no version info provided in precompiled sqlite3.dll sometimes i get confused which version i'm using. it would be nice to have an easy way to view the sqlite version. _2005-Jul-14 12:43:28 by anonymous:_ {linebreak} Yes, would be great if the version information could be put in the resources of the dll and not only be accessible through the exported function! Tools like the popular Installer "InnoSetup" could recognize the version of the sqlite3.dll then and check if a newer version is already installed...
#e8e8bd 1040 new active 2004 Dec anonymous Unknown 2005 Apr 4 4 pragma needed to enable flexibility of insert statements (esp. for awk-like filter use) In order to work around http://www.sqlite.org/cvstrac/tktview?tn=1032,3 it is possible to create insert statements manually using sed. However, those insert statements are not as flexible as they are documented to be. An error is generated if there are more data than columns. It is too slow to count the number of columns in each row to work around it. This makes the use of sqlite as an awk-like filter impossible, since you can't just define columns f1 through f9 and insert rows that have fewer columns into it. Defaulting is not done. This is inconsistent with the sqlite2 copy command, which is flexible. I propose a pragma to allow more flexibility. There is no fast workaround, but I am not assigning that severity, because in principle it is possible to much more slowly create a disk db and use .import for most purposes.
#e8e8bd 1204 new active 2005 Apr anonymous TclLib 2005 Apr drh 4 2 (visible) version provided by tclsqlite package As a new version of sqlite is released it would be good to see the tclsqlite package version modified accordingly. On the file tclsqlite.c, function Sqlite3_Init, it gives a fixed version to the function Tcl_PkgProvide "3.0". I believe this should be replaced with SQLITE_VERSION (macro defined in sqlite3.h). Is there a reason this should not happen? Or was simply overlooked?
#e8e8bd 1203 todo active 2005 Apr anonymous 2005 Apr 4 5 Web site problem, download links it seems that your download links are broken. the starting http:// is missing at the begin of a href-anchors..
#e8e8bd 1199 doc active 2005 Apr anonymous 2005 Apr 4 3 Update the README file The README file gives the following instructions: tar xzf sqlite.tar.gz ; mkdir bld ; cd bld ; ../sqlite/configure ; <== make ; make install ; I guess the indicated line should be changed to "../configure ; " since there is no "../sqlite/" directory. Kind regards. _2005-Apr-02 12:44:19 by drh:_ {linebreak} The directory is named ../sqlite-VERSION/ where VERSION is the current version number.
#e8e8bd 1190 new active 2005 Mar anonymous Unknown 2005 Mar drh 4 4 strftime() does not Support Years with 3 or 5 digits It looks like strftime() doesn't support years before 1000 CE or after 9999 CE: sqlite> select strftime('%Y', '2004-01-01T02:34:56'); strftime('%Y', '2004-01-01T02:34:56') ------------------------------------- 2004 sqlite> select strftime('%Y', '200-01-01T02:34:56'); strftime('%Y', '200-01-01T02:34:56') ------------------------------------ [null] sqlite> select strftime('%Y', '20000-01-01T02:34:56'); strftime('%Y', '20000-01-01T02:34:56') -------------------------------------- [null] The same applies to years BCE: strftime('%Y', '-2000-01-01T02:34:56') -------------------------------------- -2000 sqlite> select strftime('%Y', '-20000-01-01T02:34:56'); strftime('%Y', '-20000-01-01T02:34:56') --------------------------------------- [null] sqlite> select strftime('%Y', '-200-01-01T02:34:56'); strftime('%Y', '-200-01-01T02:34:56') ------------------------------------- [null] One can get around the requirement for pre-1000 by using a preceding 0 (and the ISO-8601 spec may well require this; I'm not sure), but the lack of support for five or more digits in the year has no workaround. So much for my science fiction database! ;-) _2005-Mar-30 23:45:53 by anonymous:_ {linebreak} Ah, found this link, which says that years must be represented by at least four digits. So 0200 is correct and works, while 200 is not. Sorry 'bout that. Ignore that part of the report. http://www.absoluteastronomy.com/encyclopedia/I/IS/ISO_86012.htm But it still would be nice to support more than four digits for the year, so that astronomy folks can use SQLite. :-) ---- _2005-Mar-31 18:24:53 by drh:_ {linebreak} I think this is an enhancement request, not a bug report. I deliberately limited the span of years that SQLite would handle to be 1000 through 9999 as a means of detecting faulty input. I reasoned that astronomers and others who were doing date calculations outside of this range are likely using their on date/time library anyhow and so the limited range of dates that SQLite would handle was not seen as a serious handicap. Even if an astronomer wanted to use SQLite, the changes to the SQLite code base to enable a larger span of years are minor and could be done on a case by case basis. I'm not sure this is something that needs to be in the standard release. ---- _2005-Mar-31 18:32:36 by anonymous:_ {linebreak} I certainly understand the desire to detect faulty input, but since dates are simply stored in TEXT columns in SQLite (I think that's right--please correct me if I'm wrong), there isn't actually any fault input detection going on until someon uses strftime() or another date/time function. Furthermore, 10000-12-19 is not faulty input; it's perfectly valid. So is -10001-02-28 (for the archaeologists). It may be easy to patch SQLite to support such dates, but that's relatively out of the hands of mere mortals. Now if there was a compile directive to enable such support, that might be a decent compromise. Then, you'd still have the validation support, but at the same time, those who need astronomical or archaeological dates could easily get them without having to learn any C or the SQLite source code. ---- _2005-Mar-31 18:55:48 by drh:_ {linebreak} I will consider the request to support 5- or 6-digit dates. But the date algorithms used in SQLite doe not work correctly for negative Julian days (that is, dates prior to -4713-11-24T12:00:00). In fact, the date algorithms always assume the Gregorian calendar, which wasn't invented until the 16th century, was not in wide use until the 18th century. So any really old dates are suspect. Due to changing standards and politics, date/time computations can be amazingly complex, especially when you start to consider things like daylight savings time. It is not the mission of SQLite to provide a complete date/time management system. The date/time functions provided are intended to give a baseline of functionality that meets 90% of the need. Users who need more can add their own code using the sqlite3_create_function() API. The date/time functions are already one of the largest modules within SQLite and I am very hesitant to go make them even larger. ---- _2005-Mar-31 19:08:30 by anonymous:_ {linebreak} Understood, thanks for the consideration.
#e8e8bd 1186 new active 2005 Mar anonymous Shell 2005 Mar 4 4 Pragma page_size doesn't set the pagesize immediately Sqlite3 doesn't change the page_size of a DB until you run a ddl command. Allthough this behavior doesn't really qualify as a bug, it is an annoyance to us. Thanks for your great work K.- M. Hansche
#e8e8bd 1184 todo active 2005 Mar danielk1977 CodeGen 2005 Mar 4 3 UTF-8 and UTF-16 substr() functions are subtly different If you pass 0 as the second argument of substr() it is interpreted differently by the two different substr() functions. The documentation doesn't say what the correct result should be. SQLite version 3.2.0 Enter ".help" for instructions sqlite> select substr('ABCDE', 0, 2); AB sqlite> pragma encoding = "utf-16"; sqlite> select substr('ABCDE', 0, 2); sqlite>
#e8e8bd 1176 new active 2005 Mar anonymous Unknown 2005 Mar 4 3 Blocking Writes I would be nice if there was an option where a write query would block when the database was locked by another process/thread. I would prefer this over returning SQLITE_BUSY and looping...Is this planned at some point?
#e8e8bd 1138 build active 2005 Feb anonymous 2005 Feb 4 3 make install fails on MinGW/MSYS trying to install into tclsh I'm building SQLite on WinXP using MinGW/MSYS system. The makefile generated with: ../sqlite/configure --with-tcl=/c/Tcl/lib works correctly to build the default target as well as the test suite, windows DLL, and import library using: make make test make implib However, I get an error whe I try to install the new version using: make install The error I get is: $ make install tclsh ../sqlite/tclinstaller.tcl 3.1 can't read "env(DESTDIR)": no such variable while executing "set LIBDIR $env(DESTDIR)[lindex $auto_path 0]" (file "../sqlite/tclinstaller.tcl" line 10) make: *** [tcl_install] Error 1 This is because the makefile is trying to install the tcl library into tcl (I think) before it installs the shell and libraries into the system. In my case this fails, so the install step never completes. I don't really care if the tcl install works or not since I'm not using it. It seems to me that the Makefile should be changed to ignore any error during this step by adding a '-' character to the beginning of the tclsh... line as shown below: tcl_install: libtclsqlite3.la -tclsh $(TOP)/tclinstaller.tcl $(VERSION) Or the install target should be split into 2 subtargets so that the normal installation subtarget is completed first as shown below: install: sqlite_install ${HAVE_TCL:1=tcl_install} sqlite_install: sqlite3 libsqlite3.la sqlite3.h $(INSTALL) -d $(DESTDIR)$(libdir) $(LTINSTALL) libsqlite3.la $(DESTDIR)$(libdir) $(INSTALL) -d $(DESTDIR)$(exec_prefix)/bin $(LTINSTALL) sqlite3 $(DESTDIR)$(exec_prefix)/bin $(INSTALL) -d $(DESTDIR)$(prefix)/include $(INSTALL) -m 0644 sqlite3.h $(DESTDIR)$(prefix)/include $(INSTALL) -d $(DESTDIR)$(libdir)/pkgconfig; $(INSTALL) -m 0644 sqlite3.pc $(DESTDIR)$(libdir)/pkgconfig; tcl_install: libtclsqlite3.la tclsh $(TOP)/tclinstaller.tcl $(VERSION) This way if an error occurrs when doing the tcl_install it will not stop the normal sqlite installation.
#e8e8bd 1061 new active 2005 Jan anonymous Shell 2005 Jan 4 4 shell.c .import from stdin e.g.: in = ( 0 == strcmp( "-", zFile ) ) ? stdin : fopen(zFile, "rb");
#e8e8bd 1029 doc active 2004 Dec anonymous Unknown 2004 Dec 4 5 SQLITE_ not SQLITE3_ constants in the C/C++ interface . html in this file : http://www.sqlite.org/capi3.html there are constants : #define SQLITE3_UTF8 1 #define SQLITE3_UTF16 2 #define SQLITE3_UTF16BE 3 #define SQLITE3_UTF16LE 4 #define SQLITE3_ANY 5 but in the code , they are SQLITE_* not SQLITE3_*
#e8e8bd 944 new active 2004 Oct anonymous Shell 2004 Oct 4 3 Command to abort current expression. It would be convenient if, at the sqlite prompt, it was possible to abort the current expression by entering e.g. a singel dot on a new line. I.e.: sqlite> SELECT * FROM ...> . sqlite>
#e8e8bd 853 doc active 2004 Aug anonymous Parser 2004 Aug 4 3 syntax of DEFAULT in a CREATE TABLE statement not as documented The syntax (as found under the syntax link on the website) indicates that a column default in a create table statement is like a column constraint definition. However, explicitly naming the column default fails. Consider: CREATE TABLE FOO( BAR VARCHAR(50) CONSTRAINT DEF_1 DEFAULT '(default)' ) yields SQL error: near "DEFAULT": syntax error
#f2dcdc 832 code active 2004 Jul anonymous Unknown 2004 Jul anonymous 4 4 os_win.c :: sqlite3OsUnlock() method has an unused variable: rc os_win.c :: sqlite3OsUnlock() method has an unused variable: rc
#e8e8bd 239 new active 2003 Feb anonymous Unknown 2004 Jul 4 2 ANSI/Unicode(Wide) version file-handling functions for Win32 As I reported in the ML, since SQLite os.c file-operation functions accept only const char *zFilename, when you build a project with SQLite source code under _UNICODE defined on Win32, their internal expectation of ANSI version function fails. For example,{linebreak}{linebreak} int sqliteOsDelete(const char *zFilename){{linebreak} #if OS_UNIX{linebreak} unlink(zFilename);{linebreak} #endif{linebreak} #if OS_WIN{linebreak} DeleteFile(zFilename);{linebreak} #endif{linebreak} #if OS_MAC{linebreak} unlink(zFilename);{linebreak} #endif{linebreak} return SQLITE_OK;{linebreak} }{linebreak}{linebreak} DeleteFile in this function is replaced with DeleteFileW, the unicode version of DeleteFile, which takes Unicode string(wide characters) as an argument.{linebreak} To compile SQLite in Unicode application, you must change those functions to its ANSI version. For DeleteFile, it's DeleteFileA. The functions that should be presented in os.c as their explicit ANSI version are:{linebreak}{linebreak} DeleteFile -> DeleteFileA{linebreak} GetFileAttributes -> GetFileAttributesA{linebreak} CreateFile -> CreateFileA{linebreak} GetFullPathName -> GetFullPathNameA{linebreak} GetTempPath -> GetTempPathA{linebreak}{linebreak} Namely, all file-handling Win32 APIs that take a path name as its argument, not a handle. The 'vanilla' versions of functions like GetFile() aren't functions, but *symbols* defined in "winbase.h". For example, GetFile() expands to: #ifdef UNICODE{linebreak} #define DeleteFile DeleteFileW{linebreak} #else{linebreak} #define DeleteFile DeleteFileA{linebreak} #endif // !UNICODE{linebreak} So when someone compiles SQLite under Windows, they need to #define _UNICODE (or not), as desired. Unless I completely misunderstand this, there is no reason to change the SQLite code, and doing so would make it less flexible. Additionally, The unicode versions of the functions *will* handle ASCII strings, which are legal UTF8 strings. So the only real consideration left is the 'offical' SQLite Windows DLL. Because older systems (95, 98) lack built-in support for the Unicode versions of most functions, the DLL should probably be built without the Unicode versions. We might want to force the definition of UNICODE when SQLITE_UTF8 is defined, so that the DLL can be queried to see what kind of strings it expects, but then, someone (me) may reasonably want to compile the app to use unicode strings for file handling, but iso8859 strings for data. So at most I would suggest a #pragma message when the two symbols disagree. This is compiler dependent, but one for MSVC, Borland, and gcc would probably catch most current users. Jim Lyon --------------------------------------------------------- (by reporter) In C++ context compiler issues error because const char* of os.c functions doesn't match DeleteFileW signature under _UNICODE defined and this is not convenient in simply adding SQLite source files in UNICODE-defined host app project. Anyway, if os.c Windows-version functions take LPCTSTR zFilename that is translated into const char* in ANSI(MBCS) and const wchar* in _UNICODE in compile-time, you don't have to use explicit ANSI version API. If explicit use of ANSI version API makes SQLite "less flexible", I'd like to propose changing const char* zFilename to LPCTSTR in os.c. Another way is, add to SQLite its own ANSI/Unicode(UCS-2) version APIs as Windows does, in Windows SQLite build. For example "open" is translated in sqlite.h to openA/openW which exists in dll. Fortunately SQLite has os.c as abstraction filter for its body, several changes in os.c will be sufficient. --------------------------------------------------------- (by reporter) It's fixed in between 3.0.0 and 3.0.2 by adding 'A' suffix to those file-handling APIs. Can someone verify and close this ticket? ---- _2004-Jul-22 23:19:23 by anonymous:_ {linebreak} SQLite 2.8.15 os.c is not fixed as of now. I think there's no reason not to apply the same replacement that favors ASCII APIs.
#e8e8bd 797 new active 2004 Jul anonymous Parser 2004 Jul 4 3 require basic named subquery / WITH sql support This ticket, derived from a recent discussion list posting, is a request for *simple* named subquery / WITH sql support. The level of support that I'm looking for should only require and update to the "Parser" subsystem, or possibly "CodeGen" too. The fundamental implementation of how SQLite handles subqueries is not changed at all. You still execute the subqueries exactly once, prior to the main queries, as you do now. The subset would be compliant with the SQL-1999 standard. As an additional reference, you can see SQL-2003 Foundation, 7.13 "" (p351). What I want is to be able to make a query like this: WITH first_subq AS ( SELECT id FROM foo WHERE name LIKE '%zoo%' ), second_subq AS ( SELECT a, b, COUNT(c) AS d FROM bar GROUP BY a, b ) SELECT * FROM second_subq AS s INNER JOIN baz AS z ON z.a = s.a AND z.b = s.b WHERE (z.opt1 IN first_subq OR z.opt2 IN first_subq) AND s.d >= z.boo ORDER BY s.d DESC One of the main advantages I cite is that SQL code is a lot cleaner and easier to understand. You can do within complex selects the same thing you can do in complex routines, which is akin to breaking out blocks into named subroutines. This advantage is particularly seen where the same subquery would be getting invoked multiple times within the main query (see example). It now does not have to be declared multiple times, leading to shorter and easier to parse SQL, and the code runs faster, because the subquery only has to be run once. As such, developers can also reduce some use of explicit temporary tables. This ticket is not requesting support for passing arguments to the named subqueries, as SQL-1999 allows, nor having support for recursive named subqueries (those that invoke themselves). Those would be nice some day, but would require more substantial changes to SQLite, such as invoking subqueries during the main query, and multiple times, rather than in advance. So I am not requesting those today. (Note that, should you ever decide to support recursive subqueries later, it should be done the SQL-1999 way, and not Oracle 8's way of start-with connect-by.) In summary, I propose that in the long run, named subqueries should be a lot more useful than inlined subqueries, both for programmer efficiency, and because SQLite itself has less work to do when parsing or optimizing sql queries; the programmer can tell you ways to optimize by reducing redundancy. Thank you. -- Darren Duncan P.S. On the list, Dennis Cote also showed a desire for the same features, saying: I also believe support for named subqueries would be a valuable addition to SQLite. I have previously advocated for this feature on the list as well, though I called it a WITH clause rather than a named subquery. It seems to me to be a fairly simple extension to SQLite that would allow the user to manually perform common sub-expression elimination optimizations. These optimizations are done automatically by other, not so lite, database engines. I also think they make the resulting SQL select statements easier to read.
#e8e8bd 762 todo active 2004 Jun anonymous Unknown 2004 Jun anonymous 4 3 Windows pre-compiled binaries are 2.8.13, not 2.8.14 Windows pre-compiled binaries are 2.8.13, not 2.8.14
#e8e8bd 752 doc active 2004 Jun anonymous 2004 Jun 4 4 FAQ-Entry: How to escape quotes Ticket #497 (not able to escape quotes) should really be mentioned in the FAQ. I'm sure many users (including me...) try to escape quotes using a backslash (C-style, like MySQL accepts it).
#e8e8bd 738 new active 2004 May anonymous 2004 May danielk1977 4 1 Sort order array in memory Order is a problem when I have in memory a result of a long query, because I must order the array of the result. For example in Ado I can use recordset.order . Is it possible with sqlite? WHere is the problem? I must do a query very time long ; if I want to sort the array that give me sqlite, I must remake the query. IT is very bad :). This because I use in virtual listview the array. char** paszResults for example Very thanks
#e8e8bd 736 new active 2004 May anonymous 2004 May 4 4 Would like to be able to list the LAST 10 lines of a query This falls outside the scope of pretty much everything, but still...{linebreak} I'd like to be able to get the last 10 lines of a query. You may argue (as the mySQL people did about 2 years back) that I can just reverse the ORDER BY direction, but it wasn't a good argument then either, because I may not be setting a specific order (I call this the natural database order). SELECT * FROM myTable LIMIT -10 makes good sense, especially as it is usually the last n items that a person tends to be most interested in. Since, as far as I know, negative limits are an undefined area, why not stake your claim to SQL fame and introduce something that will be wildly popular? Specifically:{linebreak} LIMIT -n should return the last n rows of a query.{linebreak} LIMIT k, -n should return the n rows just before the kth row{linebreak} LIMIT -k, n should return the n rows starting k rows before the end{linebreak} LIMIT -k, -n should return the kth row from the end till n rows before the end. There is good precedent for this in PHP and javascript string handling, and PHP array handling (see especially http://php.net/array_slice) Anyway, thanks for listening,{linebreak} Csaba Gabor _2004-May-13 16:53:56 by drh:_ {linebreak} "Natural" database order in SQLite is equivalent to "ORDER BY rowid". So you you can say: SELECT whatever FROM whatever ORDER BY rowid DESC LIMIT 10; And it will do what you want. And it is very fast at this. ---- _2004-May-14 02:10:20 by anonymous:_ {linebreak} Cool, that is great, thanks very much. If I understand this correctly, whenever a new insert is made (regardless of whether the location used is that of a deleted row), there is an internal rowid that always gets incremented (and would overwrite any existing rowid if a deleted row was being reused). This is, therefore, essentially an inherent PRIMARY KEY with the restriction that it can't be changed. But it could be used to access and update any existing row. Very handy, thanks. I have a related question/comment. There is a function last_insert_rowid(), but in the case of ignore (or abort) this value does not change (and why should it, after all?). But I may be interested in finding the location that the conflict occurred at. (For example, in my current application, I am entering edges in a graph. That is, I first enter the two vertices that define an edge by doing an INSERT. If the vertices already exist, however, it would be improper to do a REPLACE because previous vertex references would become invalid. No, I should really get the location of the existing vertes causing the conflict). Of course, I could manually wade through all the indeces checking to see if/where there is a conflict, but this could seriously increase my access time (we're talking thousands to millions of points) but is there not a shorthand way to find out last_attemptedInsert_row()? - well, you get the idea. Finally, since this is too tiny to make a separate thread, the last "not" of the first paragraph of text for the insert command (http://sqlite.org/lang.html#insert) should be "no". Also, I would remark that last sentence of the second paragraph for ATTACH DATABASE (http://sqlite.org/lang.html#attach) running into the third paragraph is confusing to me because the first clause of the third paragraph is repeating part of what that previous sentence was saying. Why not remove the entire first clause in the third paragraph and merge the remaining paragraph with the second one. Csaba Gabor
#f2dcdc 735 code active 2004 May anonymous Shell 2004 May 4 3 .sqliterc not processed if running on a driver other than C: In shell.c there is a snippet that reads: if (!home_dir) { home_dir = getenv("HOMEPATH"); /* Windows? */ } The HOMEPATH environment variable does not include the drive letter and needs to be concatenated with the HOMEDRIVE environment variable. _2004-May-12 14:43:40 by anonymous:_ {linebreak} That should read "drive" in the title, not "driver"
#e8e8bd 734 build active 2004 May anonymous TclLib 2004 May 4 4 libtclsqlite.xxx not built by default make all target Not a big deal but the Quickstart documentation assumes that the libtclsqllite.so (or dylib (macosx) in my case) is made & installed but the default make all target doesn't make it. You have to explicitly specify that to be made. Although, the 'Building from Source' documentation page does say that make all makes just sqlite and the basic libsqlite.{a, so, whatever} in the comment. Just a bit confusing.
#e8e8bd 727 event active 2004 May anonymous 2004 May 4 3 "wrong" affected row value returned by REPLACE When updating an existing row using the REPLACE syntax sqlite returns 1. This makes it impossible to know of an existing row was affected by the REPLACE call (1: no existing call was affected; 2: an existing row was affected). MySQL (which I assume was used as the example of the REPLACE syntax) returns a more hopeful 2 in this case. This may be due to their implementation which does an INSERT and a conditional DELETE if a contraint violation was detected due to the INSERT.
#e8e8bd 724 new active 2004 May anonymous 2004 May 4 5 VACUUM resets settings for the current session All settings tuned in current session are reverted to default values after VACUUM command execution. Example: sqlite> PRAGMA synchronous; 1 sqlite> PRAGMA synchronous=off; sqlite> PRAGMA synchronous; 0 sqlite> VACUUM; sqlite> PRAGMA synchronous; 1 I am convinced that this behavior is defined by VACUUM command implementation which reopens the database in the end. However, I think that this is an implementation detail and should not affect the session state.
#e8e8bd 689 doc active 2004 Apr anonymous 2004 Apr anonymous 4 4 Old Comment for sqlite_decode_binary in sources ? Comments in sqlite.h.in & encode.c refer to a return of -1 for an invalid data-block. I believe -1 cannot be returned. Maybe missed during jump from 1.11 to 1.12 of encode.c Works perfectly though :)
#e8e8bd 673 new active 2004 Mar anonymous Shell 2004 Apr 4 3 Format .dump nicer (patch) (I've already tried to mail this.So it goes here again.)I wanted the .dump and .schema commands to have niceroutput (better to read).So I wrote a small and simple formatter for sql.Note, that it is really simple, but should grok mostthings.Hope you like it.
#e8e8bd 566 new active 2004 Jan anonymous Unknown 2004 Jan 4 4 [PATCH] Port of sqlite and lemon to an EBCDIC mainframe I have ported sqlite (and lemon - to bootstrap sqlite) to a mainframe which features a POSIX subsystem, but in which all files are stored in EBCDIC, not in ASCII. Very few places in sqlite have codeset dependencies, so the resulting patch is rather small. I have not tested tcl (lacking a tcl-ebcdic port). I tested with a 3MB database of german bank codes and compared against a FreeBSD ASCII version. The diffs for lemon are ~280 lines. Martin Kraemer The Attachment contains the complete patch to make 2.8.9...2.8.11 compile & run on our EBCDIC platform.
#e8e8bd 563 new active 2004 Jan anonymous Parser 2004 Jan 4 3 Support for autoincrement type "SERIAL" (from PostgreSQL) I am porting my application from PostgreSQL to SQLite but I want to keep it backwards compatible. With PostgreSQL autoincrement fields are created with type SERIAL. For example: _:CREATE TABLE t1( a SERIAL PRIMARY KEY, b INTEGER); And statements like: _:INSERT INTO t1 VALUES(default,123); are used to create rows with automatically increased ids.
#e8e8bd 560 warn active 2004 Jan anonymous 2004 Jan 4 4 Warnings on commpiling using Visual C++ 6.0 Hello, I tried to create static library using Visual C++ to make SQLite internal library of my project. When I compile SQLite, I receive 44 warnings: Compiling... attach.c auth.c btree.c btree_rb.c C:\Work\projects\SQLite_lib\src\btree.c(1920) : warning C4761: integral size mismatch in argument; conversion supplied C:\Work\projects\SQLite_lib\src\btree.c(1922) : warning C4761: integral size mismatch in argument; conversion supplied C:\Work\projects\SQLite_lib\src\btree.c(537) : warning C4761: integral size mismatch in argument; conversion supplied C:\Work\projects\SQLite_lib\src\btree.c(541) : warning C4761: integral size mismatch in argument; conversion supplied C:\Work\projects\SQLite_lib\src\btree.c(559) : warning C4761: integral size mismatch in argument; conversion supplied C:\Work\projects\SQLite_lib\src\btree.c(503) : warning C4761: integral size mismatch in argument; conversion supplied C:\Work\projects\SQLite_lib\src\btree.c(504) : warning C4761: integral size mismatch in argument; conversion supplied C:\Work\projects\SQLite_lib\src\btree.c(440) : warning C4761: integral size mismatch in argument; conversion supplied C:\Work\projects\SQLite_lib\src\btree.c(451) : warning C4761: integral size mismatch in argument; conversion supplied build.c copy.c date.c C:\Work\projects\SQLite_lib\src\date.c(234) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(235) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(339) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(340) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(343) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(344) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(345) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(346) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(359) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(360) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(362) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(390) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(396) : warning C4244: '=' : conversion from 'double ' to 'long ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(503) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(510) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(584) : warning C4244: '+=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(590) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(596) : warning C4244: '+=' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(772) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(773) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\date.c(787) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data delete.c expr.c func.c hash.c insert.c main.c opcodes.c os.c C:\Work\projects\SQLite_lib\src\os.c(925) : warning C4244: 'initializing' : conversion from '__int64 ' to 'long ', possible loss of data C:\Work\projects\SQLite_lib\src\os.c(926) : warning C4244: 'initializing' : conversion from '__int64 ' to 'long ', possible loss of data C:\Work\projects\SQLite_lib\src\os.c(1017) : warning C4244: 'initializing' : conversion from '__int64 ' to 'long ', possible loss of data C:\Work\projects\SQLite_lib\src\os.c(1018) : warning C4244: 'function' : conversion from '__int64 ' to 'long ', possible loss of data pager.c C:\Work\projects\SQLite_lib\src\os.c(1018) : warning C4761: integral size mismatch in argument; conversion supplied C:\Work\projects\SQLite_lib\src\pager.c(602) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\pager.c(605) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\pager.c(720) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\pager.c(928) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\pager.c(930) : warning C4244: 'return' : conversion from '__int64 ' to 'int ', possible loss of data parse.c pragma.c parse.c(3985) : warning C4761: integral size mismatch in argument; conversion supplied parse.c(3996) : warning C4761: integral size mismatch in argument; conversion supplied printf.c random.c select.c C:\Work\projects\SQLite_lib\src\select.c(102) : warning C4018: '==' : signed/unsigned mismatch shell.c table.c tclsqlite.c tokenize.c trigger.c update.c util.c vacuum.c vdbe.c C:\Work\projects\SQLite_lib\src\vdbe.c(1295) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data C:\Work\projects\SQLite_lib\src\vdbe.c(1310) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data vdbeaux.c where.c Creating library...
_2004-Jul-22 06:42:15 by anonymous:_ {linebreak} Anything happening here ? I actually try to convince my boss to evaluate SQLite for our project but as long as there are so many warnings I have no chance. I think it's quite crucial to get a clean compile, especially those "possible loss of data" warnings are quite horrible for a database ;-)
#e8e8bd 538 new active 2003 Dec anonymous 2003 Dec 4 3 Different warnings in windows If you want the file, please contact me & I'm happy to send it through [c:\]diff -up "C:\C++ Programs\DELISprint\SQLite" "sqlite_source_windows" > "new SQLite.txt" ------------------------------------------------diff code diff -up C:\C++ Programs\DELISprint\SQLite/btree.c sqlite_source_windows/btree.c --- C:\C++ Programs\DELISprint\SQLite/btree.c Tue Dec 30 22:58:12 2003 +++ sqlite_source_windows/btree.c Wed Dec 17 19:37:30 2003 @@ -65,7 +65,7 @@ static BtCursorOps sqliteBtreeCursorOps; ** X is an unsigned integer. SWAB16 byte swaps a 16-bit integer. ** SWAB32 byteswaps a 32-bit integer. */ -#define SWAB16(B,X) ((B)->needSwab? swab16((u16)(X)) : (u16)(X)) +#define SWAB16(B,X) ((B)->needSwab? swab16((u16)X) : ((u16)X)) #define SWAB32(B,X) ((B)->needSwab? swab32(X) : (X)) #define SWAB_ADD(B,X,A) \ if((B)->needSwab){ X=swab32(swab32(X)+A); }else{ X += (A); } @@ -538,7 +538,7 @@ static void freeSpace(Btree *pBt, MemPag if( idx + iSize + size == SWAB16(pBt, pFBlk->iNext) ){ pNext = (FreeBlk*)&pPage->u.aDisk[idx + iSize + size]; if( pBt->needSwab ){ - pFBlk->iSize = swab16((u16)(swab16(pNext->iSize)+iSize+size)); + pFBlk->iSize = swab16((u16)swab16(pNext->iSize)+iSize+size); }else{ pFBlk->iSize += pNext->iSize; } diff -up C:\C++ Programs\DELISprint\SQLite/date.c sqlite_source_windows/date.c --- C:\C++ Programs\DELISprint\SQLite/date.c Tue Dec 30 22:53:08 2003 +++ sqlite_source_windows/date.c Wed Dec 17 19:37:30 2003 @@ -230,8 +230,8 @@ static void computeJD(DateTime *p){ } A = Y/100; B = 2 - A + (A/4); - X1 = (int)(365.25*(Y+4716)); - X2 = (int)(30.6001*(M+1)); + X1 = 365.25*(Y+4716); + X2 = 30.6001*(M+1); p->rJD = X1 + X2 + D + B - 1524.5; p->validJD = 1; p->validYMD = 0; @@ -335,14 +335,14 @@ static int parseDateOrTime(const char *z static void computeYMD(DateTime *p){ int Z, A, B, C, D, E, X1; if( p->validYMD ) return; - Z = (int)(p->rJD + 0.5); - A = (int)((Z - 1867216.25)/36524.25); + Z = p->rJD + 0.5; + A = (Z - 1867216.25)/36524.25; A = Z + 1 + A - (A/4); B = A + 1524; - C = (int)((B - 122.1)/365.25); - D = (int)(365.25*C); - E = (int)((B-D)/30.6001); - X1 = (int)(30.6001*E); + C = (B - 122.1)/365.25; + D = 365.25*C; + E = (B-D)/30.6001; + X1 = 30.6001*E; p->D = B - D - X1; p->M = E<14 ? E-1 : E-13; p->Y = p->M>2 ? C - 4716 : C - 4715; @@ -355,10 +355,10 @@ static void computeYMD(DateTime *p){ static void computeHMS(DateTime *p){ int Z, s; if( p->validHMS ) return; - Z = (int)(p->rJD + 0.5); - s = (int)((p->rJD + 0.5 - Z)*86400000.0 + 0.5); + Z = p->rJD + 0.5; + s = (p->rJD + 0.5 - Z)*86400000.0 + 0.5; p->s = 0.001*s; - s = (int)(p->s); + s = p->s; p->s -= s; p->h = s/3600; s -= p->h*3600; @@ -422,14 +422,14 @@ static int parseModifier(const char *zMo ** to "start of day". */ if( strncmp(z, "weekday ", 8)==0 && getValue(&z[8],&r)>0 - && (n=(int)(r))==r && n>=0 && r<7 ){ + && (n=r)==r && n>=0 && r<7 ){ int Z; computeYMD(p); p->validHMS = 0; p->validTZ = 0; p->validJD = 0; computeJD(p); - Z = (int)(p->rJD + 1.5); + Z = p->rJD + 1.5; Z %= 7; if( Z>n ) Z -= 7; p->rJD += n - Z; @@ -503,19 +503,19 @@ static int parseModifier(const char *zMo }else if( n==5 && strcmp(z,"month")==0 ){ int x, y; computeYMD(p); - p->M += (int)(r); + p->M += r; x = p->M>0 ? (p->M-1)/12 : (p->M-12)/12; p->Y += x; p->M -= x*12; p->validJD = 0; computeJD(p); - y = (int)(r); + y = r; if( y!=r ){ p->rJD += (r - y)*30.0; } }else if( n==4 && strcmp(z,"year")==0 ){ computeYMD(p); - p->Y += (int)(r); + p->Y += r; p->validJD = 0; computeJD(p); }else{ @@ -691,8 +691,8 @@ static void strftimeFunc(sqlite_func *co switch( zFmt[i] ){ case 'd': sprintf(&z[j],"%02d",x.D); j+=2; break; case 'f': { - int s = (int)(x.s); - int ms = (int)((x.s - s)*1000.0); + int s = x.s; + int ms = (x.s - s)*1000.0; sprintf(&z[j],"%02d.%03d",s,ms); j += strlen(&z[j]); break; @@ -706,7 +706,7 @@ static void strftimeFunc(sqlite_func *co y.M = 1; y.D = 1; computeJD(&y); - n = (int)(x.rJD - y.rJD + 1); + n = x.rJD - y.rJD + 1; if( zFmt[i]=='W' ){ sprintf(&z[j],"%02d",(n+6)/7); j += 2; diff -up C:\C++ Programs\DELISprint\SQLite/os.c sqlite_source_windows/os.c --- C:\C++ Programs\DELISprint\SQLite/os.c Tue Dec 30 22:42:48 2003 +++ sqlite_source_windows/os.c Wed Dec 17 19:37:30 2003 @@ -258,7 +258,7 @@ int sqliteOsDelete(const char *zFilename unlink(zFilename); #endif #if OS_WIN - DeleteFileA(zFilename); + DeleteFile(zFilename); #endif #if OS_MAC unlink(zFilename); @@ -274,7 +274,7 @@ int sqliteOsFileExists(const char *zFile return access(zFilename, 0)==0; #endif #if OS_WIN - return GetFileAttributesA(zFilename) != 0xffffffff; + return GetFileAttributes(zFilename) != 0xffffffff; #endif #if OS_MAC return access(zFilename, 0)==0; @@ -350,7 +350,7 @@ int sqliteOsOpenReadWrite( return SQLITE_OK; #endif #if OS_WIN - HANDLE h = CreateFileA(zFilename, + HANDLE h = CreateFile(zFilename, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, @@ -359,7 +359,7 @@ int sqliteOsOpenReadWrite( NULL ); if( h==INVALID_HANDLE_VALUE ){ - h = CreateFileA(zFilename, + h = CreateFile(zFilename, GENERIC_READ, FILE_SHARE_READ, NULL, @@ -482,7 +482,7 @@ int sqliteOsOpenExclusive(const char *zF }else{ fileflags = FILE_FLAG_RANDOM_ACCESS; } - h = CreateFileA(zFilename, + h = CreateFile(zFilename, GENERIC_READ | GENERIC_WRITE, 0, NULL, @@ -556,7 +556,7 @@ int sqliteOsOpenReadOnly(const char *zFi return SQLITE_OK; #endif #if OS_WIN - HANDLE h = CreateFileA(zFilename, + HANDLE h = CreateFile(zFilename, GENERIC_READ, 0, NULL, @@ -679,7 +679,7 @@ int sqliteOsTempFileName(char *zBuf){ "0123456789"; int i, j; char zTempPath[SQLITE_TEMPNAME_SIZE]; - GetTempPathA(SQLITE_TEMPNAME_SIZE-30, zTempPath); + GetTempPath(SQLITE_TEMPNAME_SIZE-30, zTempPath); for(i=strlen(zTempPath); i>0 && zTempPath[i-1]=='\\'; i--){} zTempPath[i] = 0; for(;;){ @@ -899,8 +899,8 @@ int sqliteOsSeek(OsFile *id, off_t offse #endif #if OS_WIN { - LONG upperBits = (LONG) (offset>>32); - LONG lowerBits = (LONG) (offset & 0xffffffff); + LONG upperBits = offset>>32; + LONG lowerBits = offset & 0xffffffff; DWORD rc; rc = SetFilePointer(id->h, lowerBits, &upperBits, FILE_BEGIN); /* TRACE3("SEEK rc=0x%x upper=0x%x\n", rc, upperBits); */ @@ -991,8 +991,8 @@ int sqliteOsTruncate(OsFile *id, off_t n #endif #if OS_WIN { - LONG upperBits = (LONG) (nByte>>32); - SetFilePointer(id->h, (LONG) (nByte), &upperBits, FILE_BEGIN); + LONG upperBits = nByte>>32; + SetFilePointer(id->h, nByte, &upperBits, FILE_BEGIN); SetEndOfFile(id->h); } return SQLITE_OK; @@ -1576,10 +1576,10 @@ char *sqliteOsFullPathname(const char *z char *zNotUsed; char *zFull; int nByte; - nByte = GetFullPathNameA(zRelative, 0, 0, &zNotUsed) + 1; + nByte = GetFullPathName(zRelative, 0, 0, &zNotUsed) + 1; zFull = sqliteMalloc( nByte ); if( zFull==0 ) return 0; - GetFullPathNameA(zRelative, nByte, zFull, &zNotUsed); + GetFullPathName(zRelative, nByte, zFull, &zNotUsed); return zFull; #endif #if OS_MAC diff -up C:\C++ Programs\DELISprint\SQLite/pager.c sqlite_source_windows/pager.c --- C:\C++ Programs\DELISprint\SQLite/pager.c Tue Dec 30 22:45:48 2003 +++ sqlite_source_windows/pager.c Wed Dec 17 19:37:30 2003 @@ -599,17 +599,17 @@ static int pager_playback(Pager *pPager, rc = read32bits(format, &pPager->jfd, &pPager->cksumInit); if( rc ) goto end_playback; if( nRec==0xffffffff || useJournalSize ){ - nRec = (int) ((szJ - JOURNAL_HDR_SZ(3))/JOURNAL_PG_SZ(3)); + nRec = (szJ - JOURNAL_HDR_SZ(3))/JOURNAL_PG_SZ(3); } }else{ - nRec = (int) ((szJ - JOURNAL_HDR_SZ(2))/JOURNAL_PG_SZ(2)); + nRec = (szJ - JOURNAL_HDR_SZ(2))/JOURNAL_PG_SZ(2); assert( nRec*JOURNAL_PG_SZ(2)+JOURNAL_HDR_SZ(2)==szJ ); } rc = read32bits(format, &pPager->jfd, &mxPg); if( rc!=SQLITE_OK ){ goto end_playback; } - assert( pPager->origDbSize==0 || pPager->origDbSize==(int)(mxPg) ); + assert( pPager->origDbSize==0 || pPager->origDbSize==mxPg ); rc = sqliteOsTruncate(&pPager->fd, SQLITE_PAGE_SIZE*(off_t)mxPg); if( rc!=SQLITE_OK ){ goto end_playback; @@ -717,7 +717,7 @@ static int pager_ckpt_playback(Pager *pP if( rc!=SQLITE_OK ){ goto end_ckpt_playback; } - nRec = (int)((szJ - pPager->ckptJSize)/JOURNAL_PG_SZ(journal_format)); + nRec = (szJ - pPager->ckptJSize)/JOURNAL_PG_SZ(journal_format); for(i=nRec-1; i>=0; i--){ rc = pager_playback_one_page(pPager, &pPager->jfd, journal_format); if( rc!=SQLITE_OK ){ @@ -925,9 +925,9 @@ int sqlitepager_pagecount(Pager *pPager) } n /= SQLITE_PAGE_SIZE; if( pPager->state!=SQLITE_UNLOCK ){ - pPager->dbSize = (int)(n); + pPager->dbSize = n; } - return (int)(n); + return n; } /* diff -up C:\C++ Programs\DELISprint\SQLite/parse.c sqlite_source_windows/parse.c --- C:\C++ Programs\DELISprint\SQLite/parse.c Tue Dec 30 23:00:24 2003 +++ sqlite_source_windows/parse.c Wed Dec 17 19:37:30 2003 @@ -3982,7 +3982,7 @@ void sqliteParser( yyTracePrompt,yyTokenName[yymajor]); } #endif - yy_destructor((YYCODETYPE)(yymajor),&yyminorunion); + yy_destructor(yymajor,&yyminorunion); yymajor = YYNOCODE; }else{ while( @@ -3993,7 +3993,7 @@ void sqliteParser( yy_pop_parser_stack(yypParser); } if( yypParser->yyidx < 0 || yymajor==0 ){ - yy_destructor((YYCODETYPE)(yymajor),&yyminorunion); + yy_destructor(yymajor,&yyminorunion); yy_parse_failed(yypParser); yymajor = YYNOCODE; }else if( yypParser->yytop->major!=YYERRORSYMBOL ){ diff -up C:\C++ Programs\DELISprint\SQLite/select.c sqlite_source_windows/select.c --- C:\C++ Programs\DELISprint\SQLite/select.c Tue Dec 30 22:46:48 2003 +++ sqlite_source_windows/select.c Wed Dec 17 19:37:30 2003 @@ -98,7 +98,7 @@ int sqliteJoinType(Parse *pParse, Token for(i=0; i<3 && apAll[i]; i++){ p = apAll[i]; for(j=0; jn)==keywords[j].nChar + if( p->n==keywords[j].nChar && sqliteStrNICmp(p->z, keywords[j].zKeyword, p->n)==0 ){ jointype |= keywords[j].code; break; diff -up C:\C++ Programs\DELISprint\SQLite/vdbe.c sqlite_source_windows/vdbe.c --- C:\C++ Programs\DELISprint\SQLite/vdbe.c Tue Dec 30 22:53:08 2003 +++ sqlite_source_windows/vdbe.c Wed Dec 17 19:37:30 2003 @@ -1292,7 +1292,7 @@ case OP_MustBeInt: { if( aStack[tos].flags & STK_Int ){ /* Do nothing */ }else if( aStack[tos].flags & STK_Real ){ - int i = (int)(aStack[tos].r); + int i = aStack[tos].r; double r = (double)i; if( r!=aStack[tos].r ){ goto mismatch; @@ -1307,7 +1307,7 @@ case OP_MustBeInt: { } Realify(p, tos); assert( (aStack[tos].flags & STK_Real)!=0 ); - v = (int)(aStack[tos].r); + v = aStack[tos].r; r = (double)v; if( r!=aStack[tos].r ){ goto mismatch;
------------------------------------------------diff code
#e8e8bd 391 warn active 2003 Jul anonymous 2003 Dec 4 3 signed/unsiged compiler warnings from Borland C++6 When I compile the 2.8.4 source code (as of 2003-07-14) with Borland's C++ Builder 6 compiler I get warnings about signed-unsigned comparisons and suspicious pointer conversions (int * vs unsigned *) in two files. pager.c produces the following messages: [C++ Warning] pager.c(598): W8075 Suspicious pointer conversion [C++ Warning] pager.c(613): W8012 Comparing signed and unsigned values select.c produces the following message: [C++ Warning] select.c(99): W8012 Comparing signed and unsigned values These warnings can be eliminated by the small changes detailed in the attached diff files.
#e8e8bd 348 warn active 2003 Jun anonymous Unknown 2003 Dec drh 4 3 SQLite and GCC using enhanced warning levels SQLite doesn't compile cleanly if you enable the following GCC compiler warnings: -Wcast-qual -Wmissing-declarations -Wnested-externs -Wuninitialized -Wwrite-strings Most of these can be fixed by changing "char *" to "char const *" in a few judicious places.
#e8e8bd 477 new active 2003 Oct anonymous 2003 Dec anonymous 4 4 Are there any plans to enchance SQLite to support Unicode Hi, Are there any plans to enchance SQLite to support UNICODE. Did anyone try and had any problems. I would like to use SQLite in my embedded device. I might have to modify SQLite to support UNICODE. If anyone has any points please let me know. Thanks, Use UTF8 encoding, which doesn't require 0 values, and is especially efficient for encoding ASCII text. ------- But sqlite_exec takes a char* for SQL statement. Do I need to change this peace of code or is anything simple that can be done so that I can pass unicode information ------- UTF8 encoding looks like a normal ASCIIZ string; the NUL byte is not valid UTF8 encoding, and therefore any UTF8 string can be given to SQLite, which only cares that the data be an ASCIIZ string. ------- Will SELCT lower(text), upper(text) works ? I suppouse NO... Support of unicode in some form is needed. There is no hack way to do this my client side.
#e8e8bd 525 new active 2003 Dec anonymous 2003 Dec 4 4 DB testing Hello, I have a user wich finds it annoying that non-sqlite db files can be opened (or seems to be). Would be nice to have an option like create always and open existing etc.. similar to createfile() api Thanks, Edwin Knoppert
#e8e8bd 508 doc active 2003 Nov anonymous 2003 Nov 4 4 Build instructions on home page needs link to page with platform help I just ran across SQLite and wanted to try to build it for Mac OS X. It seemed to build but kept failing the "make test" step. I dug around your site, then started googling trying to find information on building SQLite for Mac OS X. After quite a bit of searching, I finally found a link to a wiki page for cvstrac that told me exactly what I needed to know. It would be handy for other folks in the future if the following link was included in the "Building From Source" section on the main page. http://www.sqlite.org/cvstrac/wiki?p=HowToCompile
#e8e8bd 501 doc active 2003 Nov anonymous Unknown 2003 Nov anonymous 4 4 missing sqlite_encode_binary The FAQ discusses a pair of functions for binary<-->ASCII encoding in "encode.c". I grabbed the windows "pre-processed" c files and there is no such file. Nor do I see any mention of those functions (sqlite_encode_binary) in the C/C++ documentation on the website. Was this removed for some reason? Either the FAQ needs updating or the code/docs do.
#e8e8bd 498 new active 2003 Nov anonymous Unknown 2003 Nov 4 4 Suggestion: Allow named parameters. The ability to add parameters using "?" is great. However, it would be even better if you could add a meaningful names to the parameters. This would be just for human purposes, as the parser could just ignore the names. For example: "insert into mytable values (?, ?, ?)" could be written like "insert into mytable values (?Day, ?Month, ?Year)" Named parameters could also be used to allow a parameter to appear multiple times in a single query, and yet only require a single call to sqlite_bind to set its value. For example SELECT quantity FROM Inventory WHERE :price < 10 OR :price > 100; would only require a single call to sqlite_bind to set the value of the :price parameter. This feature becomes more valuable with complex queries where multiple sub-selects may require the same parameter. Implementing this feature outside SQLite would require parsing the SQL statments to locate the named parameters, substituting the positional parameters, then using the existing API to set the value of the positional parameters. This seems wasteful since SQLite will have to parse the same SQL statement again to extract the positional parameters. The colon, ":", is used by SQL:1999 as the standard prefix to denote parameter names, and should probably be adopted by SQLite as well if named parameters are implemented.
#e8e8bd 500 doc active 2003 Nov anonymous Unknown 2003 Nov 4 4 Discrepancies in comments in encode.c The explanation for how the encoder works in src/encode.c says that the offset is _added_ on encoding and _subtracted_ on decoding. However, in the actual source code the reverse is true (i.e., the offset is subtracted in sqlite_encode_binary() and added in sqlite_decode_binary()). Presumably the source is correct, so the comments should be corrected to reflect this.
#e8e8bd 303 build active 2003 May anonymous Unknown 2003 Nov a.rottmann 4 4 Makefile issues I pulled down an intermediate to test the fix for #284 and had a bit more trouble with the makefile than previously. Here are the versions from CVS/Entries: /config.guess/1.2/Mon Mar 24 09:40:35 2003// /config.sub/1.2/Mon Mar 24 09:40:35 2003// /configure/1.16/Tue Apr 22 08:04:49 2003// /configure.ac/1.5/Tue Apr 22 08:04:50 2003// And I'll attache the diff between the generated Makefile and the one I ended up with, and the configure params I used. I'm okay if you want to write off the TCL include & lib problems as due to my weird setup, and I know the double slash has been reported before, but the readline issue is probably fair game. Lastly, it's useful to note that the generated Makefile is no longer compatible with SunWorkshop make - it really requires GNU make now. _2004-Feb-26 14:50:53 by anonymous:_ {linebreak} There are several config_ variables that can be passed to the configure script; for example, the Debian package uses (from a Makefile): ./configure config_TARGET_TCL_INC="-I/usr/include/tcl8.4" config_BUILD_CFLAGS="$(CFLAGS) -DTHREADSAFE=1" Do a grep for config_ on configure.ac to see what other variables are available for tweaking. ---- _2004-Mar-09 12:46:40 by a.rottmann:_ {linebreak} I should really switch the stuff to use automake, plus using the conventional --with-foo-includes flags instead of config_ environment variables.
#e8e8bd 491 new active 2003 Nov anonymous 2003 Nov 4 4 Want to use SET col = 'val' with INSERT statement It would be nice if the an additional INSERT syntax is supported because: 1) This makes migrating from MySQL to SQLite easier. 2) The body of UPDATE and INSERT statements are the same using this syntax which makes developing faster and easier. The exact syntax: INSERT [INTO] tbl_name SET col_name=(expression | DEFAULT), ... (From: http://www.mysql.com/doc/en/INSERT.html) _2004-Mar-14 22:29:54 by anonymous:_ {linebreak} I'd like to second this item. From my readings, this is a documented feature of SQL92, and from my own use of SQL in programming languages, it's far easier to use the SET syntax over the VALUES syntax for manipulation queries. ---- _2004-May-10 10:20:25 by anonymous:_ {linebreak} My vote on this one too! When this is implemented, we can finally switch with our entire product range to sqlite :).
#e8e8bd 490 new active 2003 Nov anonymous VDBE 2003 Nov xdong 4 3 a few api improvements for recordset operations hi friends, i'm working on a visual user interface for sqlite under dos. sqlite works great and i will post a patch for short file name support. there are a few api enhancements needed for automatic synchronization of data in a recordset with the database. 1. please add a new format in printf (like %k) to convert a string to a valid sql identifier. (like rename field "from" to "[from]"). 2. additional information on a selection result will be great also: add the source table name for each column, and the rowid of each field coming from a table. a timestamp for each such field will also be of great importance, though i understand it is not present in the current code. this information will be repeated of course when there are several fields of the same table, and other way to have this information will be welcome too (such like querying the vdbe for each column of interest, every row). 3. please provide a structured way to query the fields information for a table, index, view or view order part. 4. the database dump facility should be provided as an atomic routine in the utils library. best regards, alex
#e8e8bd 128 event active 2002 Jul anonymous Unknown 2003 Oct 4 4 Workaround for problem reported in ticket 127- Replacing the misuse-5.3 test case with the following enables testfixture to continue running the quick test suite without bus error on Mac OS X 10.1.5/Tcl 8.4b4. do_test misuse-5.3 { db close catch { sqlite_exec_printf $::DB {SELECT * FROM t1} {} } result set result } {21 {library routine called out of sequence}} This problem does not appear under Linux or Win2K. It may be an issue with OS X or with the new Tcl. See also tickets #126, #127, and #129.
#e8e8bd 479 new active 2003 Oct anonymous Parser 2003 Oct drh 4 3 Sequences Adding sequences to sqlite would be very useful... allowing to do several things that are not possible today. But I'm not sure if default column values must be implemented to take full use of sequences. _2004-Mar-03 13:14:00 by anonymous:_ {linebreak} Any plans to add sequences?
#e8e8bd 465 new active 2003 Sep anonymous 2003 Sep 4 3 data types should be implemented as formated strings a real improvement of sqlite would be operating on numeric and date, time fields in a sortable string format, for example: * date as YYYYDDMM, * time as HHMMSSmmm, * integer as hexadecimal string without "0x", * float as WWWWWWWWDDDDDDDDDDDDDEEEEEEE (wholes, decimals, exponent) this way, there would be no need for the special integer keys and indexes, and code will be more feature oriented and less feature evading. hexadecimal values will compress decimals and improve sortability. all numbers should be 0-padded, prefixed by their sign, with null strings for null values. the developing effort required would be to: * make a library of basic mathematical functions for string values. * parse numeric, date, and time literals in queries without quotation marks. * match the right function for the specified type. * it would be very nice to support all the types of c variables.
#e8e8bd 454 new active 2003 Sep anonymous 2003 Sep 4 4 schema column types with parenthesis to automatically invoke functions having a table such as: CREATE TABLE foo (amount NUMERIC(10,2)); and having a function (NUMERIC) that accepts three parameters, it would be nice if: INSERT INTO TABLE foo (10.50); would call: NUMERIC(10.50,10,2); and use its result as the insert. Since this could break compatability, I recommend the use of a PRAGMA that would enable this mode. I am aware that TRIGGERS make it possible to do this, however this would require application-level setup that is too specific for some of the applications I work with; A pragma is not an unrealistic setup for my application, but setting up special INSERT/UPDATE triggers is. As a temporary workaround, my application downloads the sqlite_master table, parses out the columns, and creates the triggers accordingly. This code is somewhat complex, and thus represents an annoyance.
#e8e8bd 424 new active 2003 Aug anonymous Shell 2003 Aug 4 3 Provide access to internal function _all_whitespace() Can the function _all_whitespace() in shell.c be made available as part of the SQLite API, perhaps with the more appropriate name sqlite_empty(). This function could then be used along with sqlite_complete() when splitting files contain SQL scripts into individual statements that can be executed by SQLite. The problem occurs because sqlite_complete() returns true for an empty statment, but some applications (Borlands dbExpress for example) don't consider an empty statment to be valid SQL and throw an exception when they are executed. So the user must ensure that the statement accepted by sqlite_compltet() is not empty using the sqlite_empty() function before trying to execute it. The name _all_whitespace() is not really appropriate since it also accepts comments which are not "whitespace" characters. I am currently using a modified version of shell.c to build a custom DLL, but changing the SQLite source would be a lot cleaner.
#f2dcdc 395 code active 2003 Jul anonymous Unknown 2003 Jul 4 4 Error opening db on Mac OS X not reported correctly When sqlite is passed a directory as the database to open on Mac OS X it doesn't report an immediate error, only when you run any command does it fail. e.g.. $ mkdir 1 $ sqlite 1 SQLite version 2.8.4 Enter ".help" for instructions sqlite> .schema Error: database is locked sqlite> where on Linux it reports as I expect the code intends with: Unable to open database "contrib": disk I/O error I've tracked it down as far as I can into sqlite_open at line 162 where it calls sqliteInit - sorry my C knowhow runs out at this point. I'm more than happy to test any patches that you would like. Also I have a feeling this is related to ticket #304 that you weren't able to reproduce - presumably its a Mac OS X only problem too. Regards, PeterW. I've done some more poking about with this and it looks like the problem boils down to the line "s = fcntl(id->fd, F_SETLK, &lock);" in sqliteOsReadLock in os.c. On Mac OS X fcntl returns EISDIR when the file to lock is a directory rather than EINVAL so that the check a line or so down returns SQLITE_BUSY. On Linux this returns SQLITE_OK which causes the pager to try and find a page and causes an error when it tries to read from the directory which ends up failing with a disk I/O error. If I change the check to be: rc = (errno==EINVAL || errno==EISDIR) ? SQLITE_NOLFS : SQLITE_BUSY; then passing a directory name to open fails with the predictable error of no large file support which certainly doesn't seem like the right thing to do in this instance. Does it make to have a check right at the beginning of sqlite_open to see if the file to open is a regular file and so stop this much earlier if something other than a regular file is passed in?
#e8e8bd 407 new active 2003 Jul anonymous 2003 Jul 4 4 sqlite_compile etc. and pragma empty_result_callbacks. Maybe if EMPTY_RESULT_CALLBACKS is set and you use sqlite_compile, sqlite_step etc. with a SELECT query that returns no rows the first invocation of sqlite_step() should return SQLITE_ROW with just columns data.
#f2dcdc 403 code active 2003 Jul anonymous 2003 Jul 4 4 Two small fixes in .spec file for RPMS 1. The sqlite.pc isn't packaged in the sqlite-devel package. Simply add in the package %files section: {quote: %{_libdir}/pkgconfig/*.pc} 2. There is not %post and %postun: Need to run /sbin/ldconfig in both sections.
#e8e8bd 366 new active 2003 Jun anonymous Unknown 2003 Jun drh 4 3 Functions sqlite_(en/de)code_binary() not in sqlite.h The handy utility functions sqlite_encode_binary() and sqlite_decode_binary() from encode.c don't have any declarations in sqlite.h
#e8e8bd 362 event active 2003 Jun anonymous Shell 2003 Jun jadams 4 2 Problem with select count select count() nonetable; select count without FROM always return 1, not return error message :-)
#e8e8bd 326 new active 2003 May anonymous 2003 May 4 4 Request for additional callback for various functions There are several functions of sqlite which take callbacks as a parameter. Two of them are sqlite_create_function and sqlite_create_aggregate. I'm interfacing the sqlite with the ocaml language and it is required to do some work when the function is about to be "unregisttered", i.e. free some memory, tell the garbage collector to feel free with destroying some data and not to look for something anymore, etc. It is relatively easy to track this with auth/trace callbacks and busy handler, but for functions and aggregates I have to keep track of all registered functions ang aggregates, so the information is stored twice in a very similar structures - once inside the sqlite, once in my code. It would be easier if sqlite_create_function sqlite_create_aggregate will take one "cleanup" function as a parameter which (if not null) will be called at the time when registered function/aggregate is about to be replaced or disabled, or when sqlite structure is destroyed. This can be extended further with registering optional cleanup functions for auth/busy/trace callbacks (with calling them all when closing the database, when disabling, and when replacing), but there are workarounds for it; the real pain is only with functions and aggregates. Mikhail
#e8e8bd 321 new active 2003 May anonymous 2003 May 4 3 Make SQLITE_ISO8859 and SQLITE_UTF8 overridable by compiler define For those of us who use the preprocessed sqlite_source.zip: it would be nice if we could override the character encoding with a compiler #define. That way I wouldn't have to manually edit sqlite.h. You could put an #ifndef in sqlite.h: #ifndef SQLITE_UTF8 # define SQLITE_ISO8859 1 #endif The other #defines I use (THREADSAFE, TEMP_FILE_PREFIX) etc. are overridable. Only the encoding is not.
#e8e8bd 252 new active 2003 Feb anonymous 2003 Feb 4 1 Add optional regex matching similar to what Postgres & Oracle have It would be really nice if one could use the ~ operator for regular expression matches. Postgres does this very nicely. This one feature is a limiting factor in moving more completely to sqlite over ascii flatfiles. Using perl to slice thru stuff with regex is the only thing I miss. If I had regex matching I would be in heaven. If you are looking for a regular expression engine, I might recommend http://www.pcre.org/ _2004-May-03 15:33:30 by anonymous:_ {linebreak} I second this request. I am in charge of the Gentoo Linux Tools project, and we are developing various searching tools which we wish to have a proper database backend for. Currently, we're looking at using SQLite for this, but any speed and size advantage SQLite has over flat files for our purposes is easily removed by its inability to do regex SELECTs. I have seen that Brad Campbell has written a patch for this, but it does not appear to have shown up by SQLite release 2.8.11, nor can I find any mention of it in the change log for the past 130 days.
#e8e8bd 230 event active 2003 Jan anonymous Shell 2003 Jan anonymous 4 5 Problems compiling on AIX 4.3.3 Probably not really a bug, but a problem compiling on AIX 4.3.3 that I fixed and thought you might like to know about... During make, I got the output below. The problem turned out to be the AIX nm command itself. I used nm from gnu's bintools and it made fine. Thought you might like to know. FYI, the relevant output from make was: /usr/bin/nm -B .libs/btree.o .libs/build.o .libs/delete.o .libs/expr.o (etc, etc) nm: .libs/main.o: 0654-206 Cannot process the symbol table. ... gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I../src -DHAVE_READLINE=0 -o .libs/sqlite (etc, etc) ld: 0711-317 ERROR: Undefined symbol: .sqlite_interrupt ld: 0711-317 ERROR: Undefined symbol: .sqlite_exec ld: 0711-317 ERROR: Undefined symbol: .sqlite_open_aux_file ld: 0711-317 ERROR: Undefined symbol: .sqlite_close ld: 0711-317 ERROR: Undefined symbol: .sqlite_busy_timeout ld: 0711-317 ERROR: Undefined symbol: .sqlite_complete ld: 0711-317 ERROR: Undefined symbol: .sqlite_error_string ld: 0711-317 ERROR: Undefined symbol: .sqlite_open ld: 0711-317 ERROR: Undefined symbol: sqlite_version ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: 1254-004 The error code from the last command is 1. Stop.
#e8e8bd 192 doc active 2002 Nov anonymous Unknown 2002 Nov anonymous 4 4 Finishing build on MacOS 10.x (and other *nix's, likely) Platform: MacOS 10.x (10.2.2) Problem: "Make" of SQLite source goes fine, but using the libsqlite.a archive in an application build fails (eg., demo in Blackhole Media's ObjC wrappers, or in building Neo [http://expert.cc.purdue.edu/~mthole/neo/index.html] from source). *Errmsg: "table of contents for archive: libsqlite.a is out of date; rerun ranlib(1) (can't load from it)".* *Solution: Run "ranlib libsqlite.a" in terminal.* Explanation: (From the "ranlib" manual:) "Ranlib adds or updates the table of contents to each archive so it can be linked by the link editor, ld. The table of contents is an archive member at the beginning of the archive that indicates which symbols are defined in which library members.... Ranlib takes all correct forms of libraries (fat files containing archives, and simple archives) and updates the table of contents for all archives in the file."
#e8e8bd 129 event active 2002 Jul anonymous Unknown 2002 Jul 4 4 tcl-2.2 test fails Mac OS X 10.1.5/Tcl8.4b4 When sqlite is compiled with UTF-8 encoding, -DSQLITE_TEST and no memory debugging activated, the tcl-2.2 test fails in the context of running the quick test suite. tcl-2.2... Error: can't read "result(*)": variable isn't array When the tclsqlite.test suite is run individually, all tests pass. I worked around this by modifying the test case to unset the variable 'result' at the top of the test. do_test tcl-2.2 { catch { unset result } execsql "INSERT INTO t\u0123x VALUES(1,2.3)" db eval "SELECT * FROM t\u0123x" result break set result(*) } "a b\u1235" This problem does not appear under Linux or Win2k. It may be an issue with OS X or with the new Tcl. See also tickets #126, #127, and #128.
#e8e8bd 126 event active 2002 Jul anonymous VDBE 2002 Jul 4 5 malloc-1.195 test aborts from assert in vdbe.c Release 2.6.2 passes the quick.test suite with no errors. In further testing with the complete suite (all.test), the tests abort at malloc-1.195. The error message is given below. malloc-1.194... Ok malloc-1.195..../src/vdbe.c:5127: failed assertion `p->tos 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.
#f2dcdc 2908 code active 2008 Jan anonymous 2008 Jan 3 3 Add support to examine whether statements modify the database Currently there is no way to check whether a compiled statement will modify the database when being executed. Of course, there is the work-around of misusing the authorizer callback for this purpose, but this is kinda error prone and causes quite some overhead for such a simple purpose.
#f2dcdc 2901 code active 2008 Jan anonymous 2008 Jan 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).
#e8e8bd 2506 new active 2007 Jul anonymous 2008 Jan 3 2 New API to retrieve ROWID from SQLite3_stmt structire Is it too much trouble to allow an API to retrieve ROWID for non-aggeregate queries directly from SQLite3_stmt structire? It would be very useful to create updatable non aggregate query results for situations when actually internal PK (ROWID) is not gived explicitly in SQL statement nor actual table's PK (if any). SELECT queries that join two or more tables together would be a problem also. ---- _2007-Jul-16 16:51:18 by anonymous:_ {linebreak} It's more of a multi-step process. First you have to enumerate the open cursors on the sqlite3_stmt object. Then you need to resolve the table each cursor goes to, and then fetch the rowid for each active cursor. Of course this may get confusing when you've joined a table onto itself. ---- _2008-Jan-19 10:32:59 by anonymous:_ {linebreak} This is far to old active ticket. Is it in consideration to be implemented in the near future?
#f2dcdc 2886 code active 2008 Jan anonymous 2008 Jan 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
#f2dcdc 2882 code active 2008 Jan anonymous 2008 Jan 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 2875 code active 2008 Jan anonymous 2008 Jan 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 2860 todo active 2007 Dec anonymous 2007 Dec 3 1 Database file fragmentation Adding data in database file increases file fragmentation. for example my file which size is 1G, consists of 20000 pieces. (NTFS) This happens because truncation of '-journal' file. I see some ways to reduce fragmentaion: 1. Increase database file size by greater pieces (not by PAGESIZE). 2. SQLite can save '-journal' file in another folder(logical disc). 3. Preallocation of database file(must increase INSERT speed).
#f2dcdc 2859 code active 2007 Dec anonymous 2007 Dec 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
#f2dcdc 2761 code active 2007 Nov anonymous 2007 Dec 3 3 CLI (shell.c) should be bundled with amalgamation The CLI (shell.c) should be bundled with the amalgamation for database administrative purposes without downloading the matching shell.c from the full source tree. I second that! Qt ships with the amalgamated source files, but we also ship shell.c, whch we have to retrieve from the non-amalgamated source files. ---- _2007-Dec-26 15:20:04 by anonymous:_ {linebreak} I also agree. It is inconvenient to retrieve the matching shell.c from the source tree.
#f2dcdc 368 code active 2003 Jun anonymous 2007 Dec 3 4 UPDATE trigger doesn't fire on INSERT OR REPLACE After executing the following SQL, there will be nothing in table T2. I expect to see '1' there: CREATE TABLE T1 ( id, name ); CREATE TABLE T2 ( id ); CREATE TRIGGER T1A AFTER UPDATE ON T1 BEGIN INSERT INTO T2 VALUES( new.id ); END; INSERT INTO T1 VALUES (1, 'Hi'); INSERT INTO T1 VALUES (2, 'There'); INSERT OR REPLACE INTO T1 VALUES (1,'Me'); An INSERT trigger *does* fire on INSERT OR REPLACE if the item exists already -- I would expect an UPDATE trigger. ---- _2004-Sep-21 17:15:37 by anonymous:_ {linebreak} Still repros in 3.0.7 :-( ---- _2007-Dec-17 21:45:03 by anonymous:_ {linebreak} I would say that ON DELETE and ON INSERT better describes what really happens (and not ON UPDATE), because if there would be another columns in the '1' row, their values would not be preserved after INSERT OR REPLACE takes place, as the documentation of the ON REPLACE algorithm states: "When a UNIQUE constraint violation occurs, the pre-existing rows that are causing the constraint violation are removed prior to inserting or updating the current row". However, neither ON UPDATE nor ON DELETE trigger occurs, which still is a bug. Thank you.
#e8e8bd 2831 new active 2007 Dec anonymous 2007 Dec 3 4 alter view View can't be used after ALTER RENAME TO: SQLite version 3.5.3 Enter ".help" for istructions sqlite> create table t(a); sqlite> create view v1 as select * from t; sqlite> alter table v1 rename to v2; sqlite> select * from v2; SQL error: no such table: v2 sqlite> select * from v1; SQL error: no such table: v1 sqlite> .schema CREATE TABLE t(a); CREATE VIEW v1 as select * from t; sqlite> select * from sqlite_master; table|t|t|2|CREATE TABLE t(a) view|v1|v1|0|CREATE VIEW v1 as select * from t
This is a feature request, not a bug. ---- _2007-Dec-11 18:40:17 by anonymous:_ {linebreak} Notice that alter table doesn't return an error. After the command neither v1 nor v2 can be used. ---- _2007-Dec-13 08:18:16 by danielk1977:_ {linebreak} [4623] improves the situation by returning an error when the user attempts to rename a view. One reason this feature (renaming views) is not a high priority is because a view can be dropped and recreated with a different name efficiently. This was not the case with tables.
#f2dcdc 2825 code active 2007 Dec anonymous 2007 Dec 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 }
#e8e8bd 2821 new active 2007 Dec anonymous 2007 Dec 3 4 hashtable indicies It would be nice to implement non btree indices. I.e. CREATE INDEX ON table(rowid) AS HASH. Using a hashtable's O(1) properties, you could use the index for very quick lookups when one result is expected. This does have the tradeoff that a hashtable index has no ordering properties (can not be used for sorts or non-equality searching). However, it would be a *huge* win when you have 250,000 rowids in memory, and you want to go fetch another column in the database for each one of those rowids (SELECT * FROM table WHERE rowid=?). _2007-Dec-03 21:58:01 by anonymous:_ {linebreak} For 250,000 rows I doubt you would see that much of an improvement (try it.) You'll almost certainly find log_n is going to be fairly fast (especially for large n.) I personally would prefer some sort of 'virtual' index though, that could be a hash or actually from a user-supplied function so that I can index large blobs by some function (i.e. a hash). And yes, this would be an incompatible file-format change and it's not clear how to update an index when the function isn't loaded (i.e. db reopened with that function.) Perhaps mark the index as 'stale' and ignore it until the function loads then you can do the updates. Of course this starts to get quite complicated. ---- _2007-Dec-03 22:12:17 by anonymous:_ {linebreak} Everything in sqlite depends on btree indexes. You're talking a major rewrite if you support hash-based or other indexing.
#f2dcdc 2814 code active 2007 Nov anonymous 2007 Dec 3 3 _XOPEN_SOURCE again Ideally setting _XOPEN_SOURCE should be an opt-in detected by configure, rather than a hardcoded opt-out as it is now. I find you create more problems in setting it than just leaving it out on modern platforms. Can you please give users the option of not defining _XOPEN_SOURCE at all? +#ifndef SQLITE_DONT_DEFINE_XOPEN_SOURCE #if !defined(_XOPEN_SOURCE) && !defined(__DARWIN__) && SQLITE_THREADSAFE # define _XOPEN_SOURCE 500 /* Needed to enable pthread recursive mutexes */ #endif +#endif
_2007-Dec-01 09:23:15 by anonymous:_ {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 2223 code active 2007 Feb scouten 2007 Nov 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.
#f2dcdc 2793 code active 2007 Nov anonymous 2007 Nov 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
#e8e8bd 2417 new active 2007 Jun anonymous 2007 Nov drh 3 3 Idea for read write concurrency. This is not a problem, but rather an idea on how to resolve the reader/writer concurrency issues encountered in sqlite. The idea is to allow a reader and writer to work concurrently not blocking each other. Dual writers would of course block. When a write occurs: 1. block level changes are made to the database file. 2. Pre-image of that change is written to the journal. Readers: 1. File I/O on the main file would occur normally. 2. If the block encountered is "new" ie one that was written out by the writer. Then get the original block from the Journal file. In order to determine "NEW" a change number could be put on each block. When a READ (select) begins it would first determine the starting global change number. (maybe on the master block?) When a write occurs it would read the Master blocks change number. (increment this in memory) and use write new blocks with the new value. At commit. The Master block would be updated and the txn journal marked for purge if there are pending reads. -- Drawbacks: Reading becomes dependent upon the txn journal. -- Implementation of BLOCK level versioning may ultimately be a simpler approach. Idea would be for a seperate file conaining versioned blocks. This file could be accessed instead of the txn journal. _2007-Nov-08 15:12:00 by anonymous:_ {linebreak} DRH: Also unaddressed in the proposal is how to locate a particular page within the journal file without having to do (performance killing) sequential scan of the possible very large file. Resolution of page access to avoid sequential scans of Txn Journal. When a writer is making the modification to a page first it writes the original page to the journal. At this point the journal file offset location is known. Save this offset in the "NEW" page being written into the database file. This implements a backwards chaining of pages into the txn journal. The reader upon reading the db file page would recognize (see above) that the page is dirty. Acquire the txn journal offset from the dirty page, Read the page from the journal until the starting page is found. This would eliminate any sequential scanning, but may require more than one read request.
#f2dcdc 2755 code active 2007 Nov anonymous 2007 Nov 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
#f2dcdc 2753 code active 2007 Nov anonymous 2007 Nov drh 3 3 Master journal files sometimes not deleted In the 3.4.1 amalgamation, in vdbeCommit, the master journal file is created, and deleted at the end or if there is an error. But it looks like there is one case where it gets closed but not deleted. The code is: for(i=0; rc==SQLITE_OK && inDb; i++){ Btree *pBt = db->aDb[i].pBt; if( pBt && sqlite3BtreeIsInTrans(pBt) ){ rc = sqlite3BtreeCommitPhaseOne(pBt, zMaster); } } sqlite3OsClose(&master); if( rc!=SQLITE_OK ){ sqliteFree(zMaster); return rc; } It seems like that last bit should be: if( rc!=SQLITE_OK ){ sqlite3OsDelete(zMaster); sqliteFree(zMaster); return rc; } _2007-Nov-01 19:26:28 by anonymous:_ {linebreak} Should have read the comment above that code segment closer. Looks like this was by design. Trying to figure out what to do with the client that has hundreds of orphaned master journal files...
#e8e8bd 2749 warn active 2007 Oct anonymous 2007 Oct 3 4 SQLITE_OMIT_FLOATING_POINT, int constants too large Hiya! i'm working from the 3.5.1 (CVS version) of the amalgamation. The code was pulled from CVS sometime around Oct 27th 2007. Platform: Kubuntu Linux 7.04, i386-32, gcc 4.1.2. The compiler output says it all: gcc -c -DSQLITE_OMIT_FLOATING_POINT sqlite3.c sqlite3.c: In function 'bestVirtualIndex': sqlite3.c:65531: warning: integer constant is too large for 'long' type sqlite3.c: In function 'bestIndex': sqlite3.c:65600: warning: integer constant is too large for 'long' type sqlite3.c: In function 'sqlite3WhereBegin': sqlite3.c:66223: warning: integer constant is too large for 'long' type sqlite3.c:66248: warning: integer constant is too large for 'long' type sqlite3.c:66254: warning: integer constant is too large for 'long' type These warnings would seem to indicate potentially serious problems, though i admittedly have not investigated whether overflows are really fatal in the affected contexts.
#f2dcdc 2714 code active 2007 Oct anonymous 2007 Oct drh 3 4 Shell cannot import large files greater than 2 GB [patch] If I issue an .import command within the SQLite shell and the file size is larger than 2 GB, the shell gives the error message "cannot open file: foo.txt". Putting #define _FILE_OFFSET_BITS 64 before the #include statements in shell.c fixes this problem under Linux. I tested this solution with a 2.6 GB file under Ubuntu Feisty Fawn 7.04 with Linux kernel 2.6.20-16-generic. _2007-Oct-12 18:48:35 by drh:_ {linebreak} I'm not convinced SQLite _should_ be able to import files larger than 2GiB. Does anybody really ever need to read more than 2GiB of SQL text? That is a lot of SQL, don't you think? Is this really a desirable feature? Can you not split it up into two or more smaller files? ---- _2007-Oct-14 09:25:42 by anonymous:_ {linebreak} I'm not 100% certain about this but: #define _FILE_OFFSET_BITS 64 isn't necessarily correct, better to tweak the makefile(s): CFLAGS += $(shell getconf LFS_CLFAGS) (similar for LDFLAGS) should work on 32/64 bit machines and different platforms. For shell.c I really wouldn't bother and think this should be left alone. Using .import for load more than 2GB makes me things the shell should be fleshed out and extended for this sort of abuse, handy as it is right now, it's not a full SQL shell but a minimalist shell and a useful example). ---- _2007-Oct-16 14:08:09 by anonymous:_ {linebreak} I am the original poster. I use the shell to import CSV files in the 3-4 GiB range on a daily basis. I don't see the point of splitting the files or writing my own importer when the shell does a perfectly fine job once large file support has been activated. With all due respect, I don't understand the reluctance to enable a useful feature. Shouldn't the user decide whether it is reasonable for his application to import big files? I work in the health care industry processing insurance claims for several very large companies. There's nothing broken or wrong with my application -- big files are just the nature of the data I'm handling. Neither of you has proposed any disadvantage to enabling LFS in the shell. If there are no drawbacks, why not turn it on? If the core library can open large database files, why shouldn't the shell be able to import large ones? ---- _2007-Oct-16 16:24:22 by anonymous:_ {linebreak} For reasons also unknown to me, the authors appear to regard the shell as a largely unused sample program. Based on my personal experience in talking to various sqlite library users, it is the primary administrative front-end for sqlite. In particular, doing backups and merging databases.
#f2dcdc 2703 code active 2007 Oct anonymous 2007 Oct 3 4 make test does not work with SQLITE_OMIT_FLOATING_POINT make test cannot run with SQLITE_OMIT_FLOATING_POINT. Shouldn't these tests be skipped? ./src/test1.c:1255: warning: passing argument 3 of ‘Tcl_GetDouble’ from incompatible pointer type ./src/test1.c: In function ‘sqlite3_mprintf_scaled’: ./src/test1.c:1284: warning: passing argument 3 of ‘Tcl_GetDouble’ from incompatible pointer type ./src/test1.c: In function ‘test_bind_double’: ./src/test1.c:2607: warning: passing argument 3 of ‘Tcl_GetDoubleFromObj’ from incompatible pointer type ./src/tclsqlite.c: In function ‘tclSqlFunc’: ./src/tclsqlite.c:728: warning: passing argument 3 of ‘Tcl_GetDoubleFromObj’ from incompatible pointer type ./src/tclsqlite.c: In function ‘DbObjCmd’: ./src/tclsqlite.c:1609: warning: passing argument 3 of ‘Tcl_GetDoubleFromObj’ from incompatible pointer type ... $ ./testfixture test/select1.test select1-1.1... Ok select1-1.2... Ok select1-1.3... Ok select1-1.4... Ok select1-1.5... Ok select1-1.6... Ok select1-1.7... Ok select1-1.8... Ok select1-1.8.1... Ok select1-1.8.2... Ok select1-1.8.3... Ok ./testfixture: near ".": syntax error while executing "db eval {INSERT INTO test2(r1,r2) VALUES(1.1,2.2)}" ("uplevel" body line 1) invoked from within "uplevel [list $db eval $sql]" (procedure "execsql" line 3) invoked from within "execsql {INSERT INTO test2(r1,r2) VALUES(1.1,2.2)}" (file "test/select1.test" line 69)
#f2dcdc 2674 code active 2007 Sep anonymous 2007 Sep 3 4 NFS fails without lock manager *Problem:* SQLite fails entirely if the NFS lock manager is not running on the share hosting the DB -- even when all access to the DB is serialized. Under these circumstances, it becomes difficult to create applications that are capable of running in a multitude of environments because restrictions are now imposed upon the storage location. ---- *Reproduction:* *:setup an NFS share *:disable the lock manager *:attempt to perform any transactions on a db on that share *:start the lock manager *:perform the same operations ---- *Request:* *:Make a change to the error handling, as necessary, to allow processes to access a DB over an NFS share without use of a lock manager. *:Make a big bold flashing sign in the FAQ about this failure-mode. The wording of the current FAQ led us to believe that the transaction would go through, but protection from other processes was not guaranteed. ---- *Shameless Fanmail:* Love the product! ---- *Screenshot:* dev-srs08 ~ # [__db_init .c:384] Statement: CREATE TABLE versions ( id INTEGER PRIMARY KEY AUTOINCREMENT, version INTEGER, tbl CHAR(256) ); Failed with error: database is locked [main .c:1096] Unable to init output DB: /mnt/nfs/o dev-srs08 ~ # /etc/init.d/nfslock start Starting NFS statd: [ OK ] dev-srs08 ~ # dev-srs08 ~ # _2007-Sep-28 04:35:00 by anonymous:_ {linebreak} Yet another reason to avoid using SQLite on remote shares. ---- _2007-Sep-29 18:04:19 by anonymous:_ {linebreak} _Make a change to the error handling, as necessary, to allow processes to access a DB over an NFS share without use of a lock manager._ By design the SQLite library guarantees ACID. It can't provide that without file locks. In my opinion a non-ACID version would be a custom version, which you can (should) build yourself. The source is available, or there might already be a compilation option to accomplish that. _Make a big bold flashing sign in the FAQ about this failure-mode. The wording of the current FAQ led us to believe that the transaction would go through, but protection from other processes was not guaranteed._ FAQ (5) "When any process wants to write, it *must lock* the entire database file for the duration of its update." seems to be quite clear. -knu-
#f2dcdc 2653 code active 2007 Sep anonymous 2007 Sep 3 4 Exclusive Transactions do not work with a Database File attached twice Regarding the docs, it is possible to attach the same database file multiple times. After doing so, I wanted to begin an exclusive transaction. Unfortunately, this fails ("database is locked") and surprises me as I did not find any notice on this particular situation and possible side-effects neither in the attach nor in the transaction/locking documentation. If this behaviour is seen as an error, It would be useful to have it error fixed, because if one reads a list of (possibly duplicate) database files but with unique identifiers, it would be helpful to use these defined identifiers when accessing the databases (and that in an exclusive transaction). Real-world case: Each "module" uses its own database file. Some modules share a database file. So there is a list of module -> database file assignments. Now an update process gets some database update scripts from the modules. Every module wants its changes to be done in the right database, so it relies on having its own database attached with an unique identifier - the module's name. On the other hand, the update process need exclusive access to the databases and starts a transaction -- bummer.
#f2dcdc 2627 code active 2007 Sep anonymous 2007 Sep 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
#f2dcdc 2634 code active 2007 Sep anonymous 2007 Sep 3 3 .schema uses incorrect ORDER BY giving wrong dependency order When the schema is exported, views are sorted by name instead of by dependency. If there are nested views, the schema may be invalid when used to re-create the database. sqlite3 create table t ( f text ); create view v2 as select f from t; create view v1 as select f from v2; .output test.txt .schema .exit sqlite3 .read test.txt SQL error near line 2: no such table: main.v2 _2007-Sep-07 15:33:06 by anonymous:_ {linebreak} Use .dump instead as a workaround. Unlike .schema, .dump does not use ORDER BY in its queries on sqlite_master and it outputs its rows in order of entry. SQLite version 3.5.0 Enter ".help" for instructions sqlite> create table t ( f text ); sqlite> create view v2 as select f from t; sqlite> create view v1 as select f from v2; sqlite> sqlite> .schema CREATE TABLE t ( f text ); CREATE VIEW v1 as select f from v2; CREATE VIEW v2 as select f from t; sqlite> sqlite> .dump BEGIN TRANSACTION; CREATE TABLE t ( f text ); CREATE VIEW v2 as select f from t; CREATE VIEW v1 as select f from v2; COMMIT;
Suggested patch: Index: src/shell.c =================================================================== RCS file: /sqlite/sqlite/src/shell.c,v retrieving revision 1.167 diff -u -3 -p -r1.167 shell.c --- src/shell.c 7 Sep 2007 01:12:32 -0000 1.167 +++ src/shell.c 7 Sep 2007 15:28:24 -0000 @@ -1411,8 +1411,7 @@ static int do_meta_command(char *zLine, "SELECT sql FROM " " (SELECT * FROM sqlite_master UNION ALL" " SELECT * FROM sqlite_temp_master) " - "WHERE tbl_name LIKE shellstatic() AND type!='meta' AND sql NOTNULL " - "ORDER BY substr(type,2,1), name", + "WHERE tbl_name LIKE shellstatic() AND type!='meta' AND sql NOTNULL", callback, &data, &zErrMsg); zShellStatic = 0; } @@ -1421,8 +1420,7 @@ static int do_meta_command(char *zLine, "SELECT sql FROM " " (SELECT * FROM sqlite_master UNION ALL" " SELECT * FROM sqlite_temp_master) " - "WHERE type!='meta' AND sql NOTNULL AND name NOT LIKE 'sqlite_%'" - "ORDER BY substr(type,2,1), name", + "WHERE type!='meta' AND sql NOTNULL AND name NOT LIKE 'sqlite_%'", callback, &data, &zErrMsg ); }
after patch: SQLite version 3.5.0 Enter ".help" for instructions sqlite> create table t ( f text ); sqlite> create view v2 as select f from t; sqlite> create view v1 as select f from v2; sqlite> .schema CREATE TABLE t ( f text ); CREATE VIEW v2 as select f from t; CREATE VIEW v1 as select f from v2; sqlite> .q
#e8e8bd 2587 build active 2007 Aug anonymous 2007 Aug 3 4 Build problem when using the SQLITE_OMIT_FLOATING_POINT define. I apologize in advance if the values I chose above are not appropriate. If I define SQLITE_OMIT_FLOATING_POINT=1 and try to build a Windows DLL, I get two errors in loadext.c, line 116 and 192. "error C4028: formal para meter 3 different from declaration" I believe you want to change the include order at the top of loadext.c from: #include "sqlite3ext.h" #include "sqliteInt.h" to: #include "sqliteInt.h" #include "sqlite3ext.h" Reversing the order of include fixes my build. Yes, I know there is no real reason to disable floating point for the Windows DLL. I'm actually porting SqLite for use in an NT kernel mode driver and avoiding floating point operations will save a lot of time if I don't really need them and I don't. So I made sure this was a problem with a supported platform like the Windows DLL and griped about that instead of my insanity. ;-) You can email questons to mspiegel@vipmail.com. If you want to discuss this over the phone, shoot me an email and I'll send you phone numbers.
#e8e8bd 2568 new active 2007 Aug anonymous 2007 Aug 3 3 TEMP_STORE is ignored in some cases It seems that sometimes TEMP_STORE is ignored. I've tried to force SQLite to always use memory by setting TEMP_STORE=3, but some etilqs_* temp files are still being created. The call stack that's causing these file to be created is: sqlite3PagerOpentemp(OsFile * *) sqlite3PagerStmtBegin(Pager *) sqlite3BtreeBeginStmt(Btree *) sqlite3VdbeExec(Vdbe *) sqlite3Step(Vdbe *) sqlite3_step(sqlite3_stmt *) It looks like the temp files are being used to store information for undoing earlier parts of a transaction if a later part fails. I'm assuming the fact this part of the code ignores TEMP_STORE is an over site? _2007-Aug-13 15:03:19 by drh:_ {linebreak} The TEMP_STORE compile-time option only changes the storage for temporary database files. The statement journal is not a databaes file and thus does not come under the control of TEMP_STORE. There is currently no mechanism to force the statement journal into memory instead of onto disk. I will reclassify this ticket as a "feature request". ---- _2007-Aug-22 10:42:50 by anonymous:_ {linebreak} Okay, thank you.
#f2dcdc 1242 code active 2005 May anonymous Shell 2007 Aug 3 4 EXPLAIN causes segmentation fault on OSX (and linux) Under Mac OS X, EXPLAIN causes a segmentation fault: [jacob@046] ~$ sqlite3 foo.db SQLite version 3.2.1 Enter ".help" for instructions sqlite> CREATE TABLE test (a int, b int); sqlite> EXPLAIN SELECT * FROM test; Segmentation fault The crash dump follows: Host Name: jacobian Date/Time: 2005-05-13 09:17:04.860 -0500 OS Version: 10.4 (Build 8A428) Report Version: 3 Command: sqlite3 Path: /usr/local/bin/sqlite3 Parent: bash [15421] Version: ??? (???) PID: 15544 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x1400fffc Thread 0 Crashed: 0 libSystem.B.dylib 0x90003228 strlen + 8 1 libsqlite3.0.dylib 0x002387c8 sqlite3VdbeList + 284 (vdbeaux.c:609) 2 libsqlite3.0.dylib 0x002376e0 sqlite3_step + 312 (vdbeapi.c:207) 3 libsqlite3.0.dylib 0x0023e5d8 sqlite3_exec + 260 (legacy.c:82) 4 sqlite3 0x00005b64 process_input + 808 (shell.c:1504) 5 sqlite3 0x000062bc main + 1528 (shell.c:1790) 6 sqlite3 0x00001db4 _start + 348 (crt.c:272) 7 sqlite3 0x00001c54 start + 60 Thread 0 crashed with PPC Thread State: srr0: 0x90003228 srr1: 0x0000d030 vrsave: 0x00000000 cr: 0x22444428 xer: 0x00000006 lr: 0x002387c8 ctr: 0x90003220 r0: 0x002387c8 r1: 0xbfffef40 r2: 0x00249a00 r3: 0x1400fffe r4: 0x00000028 r5: 0x00000000 r6: 0x00000001 r7: 0xffffffff r8: 0x00000001 r9: 0x1400fffc r10: 0x00000086 r11: 0x00249180 r12: 0x90003220 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0xbffff0f8 r18: 0x00000000 r19: 0xbffff17c r20: 0x00000000 r21: 0x000036d0 r22: 0x00303d90 r23: 0x00303d74 r24: 0x01805700 r25: 0x01807e00 r26: 0x00000001 r27: 0x00000004 r28: 0x01805640 r29: 0x01805600 r30: 0x01805200 r31: 0x002386bc Binary Images Description: 0x1000 - 0x7fff sqlite3 /usr/local/bin/sqlite3 0x205000 - 0x248fff libsqlite3.0.dylib /usr/local/lib/libsqlite3.0.dylib 0x8fe00000 - 0x8fe50fff dyld 43 /usr/lib/dyld 0x90000000 - 0x901a6fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x901fe000 - 0x90202fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x91d33000 - 0x91d53fff libmx.A.dylib /usr/lib/libmx.A.dylib 0x9680c000 - 0x9683afff libncurses.5.4.dylib /usr/lib/libncurses.5.4.dylib 0x969a3000 - 0x969b9fff libedit.2.dylib /usr/lib/libedit.2.dylib Happening to me as well on FC6 sqlite3 version 3.3.6 ---- _2007-Aug-21 17:09:34 by anonymous:_ {linebreak} Try to upgrade to 3.4.2.
#e8e8bd 2567 build active 2007 Aug anonymous 2007 Aug 3 2 Build fails to install I compile under MinGW with Msys. A build error occurs during 'make install'. After checking the makefile. The 'install' target depends on 'sqlite3', when it should be 'sqlite3$(TEXE)'. The workaround is, after configure, edit makefile for target install, and replace 'sqlite3' with 'sqlite3${TEXE}' where needed. I did not have this problem with 3.3.17. I assume this could be fixed just by fixing the configure to produce correct makefile. _2007-Aug-12 04:41:12 by anonymous:_ {linebreak} Do you have a patch?
#f2dcdc 2503 code active 2007 Jul anonymous 2007 Jul 3 4 sqlite3PagerReleaseMemory does not decrement page count When cached pages are released by sqlite3PagerReleaseMemory the number of pages (pPager->nPage) is not decremented. This also subsequently affects the maximum value at pPager->nMaxPage. This does not affect the operation of sqlite (but does upset my statistic gathering). Although only tested with 3.3.8, the problem does not appear to have been corrected in version 3.4.0 Actually this will affect the handling of cache_size as the pager will think there are more pages cached than is the case, and may unnecessarily release some. ---- _2007-Jul-18 15:54:29 by anonymous:_ {linebreak} Do you have a simple test case that demonstrates this? Put a print statement in pager.c if necessary.
#f2dcdc 2511 code active 2007 Jul anonymous 2007 Jul 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
#f2dcdc 2498 code active 2007 Jul anonymous 2007 Jul 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. /* ** 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.
#e8e8bd 2473 warn active 2007 Jun anonymous 2007 Jun anonymous 3 2 sqlite memory org. on linux i use sqlite on linux (2.4.35) and on FreePascal... i write an simple example code on linux_&_sqlite_&_freepascal. when working my example code on tty1, i run ps command on tty2; multiple process id showing about my example program... my example code is very simple... before v3.3.13 : no problem; but v3.3.17 and later is wrong... (excuse my poor english) _2007-Jun-28 13:10:10 by anonymous:_ {linebreak} There is no bug mentioned in this ticket. ---- _2007-Jun-28 14:09:36 by drh:_ {linebreak} I think I see a hint of a bug report in the description where it says "before v3.3.13: no problem; but v3.3.17 and later is wrong". But that is not anything near enough information to isolate and fix the problem. halukduman09: Please find a friend or coworker who speaks good English and ask that person to translate for you. We can only help you if we can understand what you are saying. Thanks.
#e8e8bd 2443 new active 2007 Jun anonymous 2007 Jun 3 3 sqlite should return different exit codes for different errors sqlite should return different exit codes for different errors reported. sqlite always returns exit code 0 or 1. It would be helpful to have different codes. I/O error, locked, interrupted, busy etc. should declare defined return codes. If sqlite is executed from a shell script it is difficult to handle plain text that could change or be reformatted in a later version. Thanks. _2007-Jun-21 19:59:41 by anonymous:_ {linebreak} Just run sqlite3 -batch -bail and grep for the error in the last line.
#e8e8bd 2438 new active 2007 Jun rse 2007 Jun 3 3 More easily allow the building of SQLite with FTS1 and FTS2 I don't know what the _intended_ way is to build SQLite with FTS1 and/or FTS2, but for the OpenPKG "sqlite" package I at least now use the following change -- as I was unable to find any other automated solution. I know that FTS1 and FTS2 are experimental extensions, but if it is too complicated for people to build SQLite with them, they certainly will never become non-experimental ;-) So I recommend to at least provide some build-time glue for them. In the OpenPKG "sqlite" package I now use the following patch which at least provides this glue (one still has to enable it, of course): Index: Makefile.in --- Makefile.in.orig 2007-06-14 22:54:38 +0200 +++ Makefile.in 2007-06-20 18:09:00 +0200 @@ -130,6 +130,18 @@ vdbe.lo vdbeapi.lo vdbeaux.lo vdbeblob.lo vdbefifo.lo vdbemem.lo \ where.lo utf.lo legacy.lo vtab.lo +# FTS1 support +ifdef FTS1 +TCC += -DSQLITE_ENABLE_FTS1 +LIBOBJ += fts1.lo fts1_hash.lo fts1_porter.lo fts1_tokenizer1.lo +endif + +# FTS2 support +ifdef FTS2 +TCC += -DSQLITE_ENABLE_FTS2 +LIBOBJ += fts2.lo fts2_hash.lo fts2_porter.lo fts2_tokenizer1.lo +endif + # All of the source code files. # SRC = \ @@ -498,6 +510,23 @@ -o testfixture $(TESTSRC) $(TOP)/src/tclsqlite.c \ libsqlite3.la $(LIBTCL) +fts1.lo: $(TOP)/ext/fts1/fts1.c $(HDR) + $(LTCOMPILE) -c $(TOP)/ext/fts1/fts1.c +fts1_hash.lo: $(TOP)/ext/fts1/fts1_hash.c $(HDR) + $(LTCOMPILE) -c $(TOP)/ext/fts1/fts1_hash.c +fts1_porter.lo: $(TOP)/ext/fts1/fts1_porter.c $(HDR) + $(LTCOMPILE) -c $(TOP)/ext/fts1/fts1_porter.c +fts1_tokenizer1.lo: $(TOP)/ext/fts1/fts1_tokenizer1.c $(HDR) + $(LTCOMPILE) -c $(TOP)/ext/fts1/fts1_tokenizer1.c + +fts2.lo: $(TOP)/ext/fts2/fts2.c $(HDR) + $(LTCOMPILE) -c $(TOP)/ext/fts2/fts2.c +fts2_hash.lo: $(TOP)/ext/fts2/fts2_hash.c $(HDR) + $(LTCOMPILE) -c $(TOP)/ext/fts2/fts2_hash.c +fts2_porter.lo: $(TOP)/ext/fts2/fts2_porter.c $(HDR) + $(LTCOMPILE) -c $(TOP)/ext/fts2/fts2_porter.c +fts2_tokenizer1.lo: $(TOP)/ext/fts2/fts2_tokenizer1.c $(HDR) + $(LTCOMPILE) -c $(TOP)/ext/fts2/fts2_tokenizer1.c fulltest: testfixture$(TEXE) sqlite3$(TEXE) ./testfixture $(TOP)/test/all.test
#f2dcdc 154 code active 2002 Sep drh Pager 2007 Jun 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 2383 code active 2007 May anonymous 2007 May 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 2381 doc active 2007 May anonymous 2007 May 3 3 'VACUUM' aborts an active transaction. *VACUUM* aborts an active transaction. I'm not sure if this is the intended behavior. I didn't see any documentation to this effect. sqlite> .sc CREATE TABLE bar ( c1 integer primary key not null ); sqlite> select max(oid) from bar; count(oid) ---------- 240 sqlite> begin; sqlite> delete from bar; sqlite> select max(oid) from bar; mcount(oid) ---------- 0 sqlite> vacuum; SQL error: cannot VACUUM from within a transaction sqlite> select max(oid) from bar; count(oid) ---------- 240
#f2dcdc 2363 code active 2007 May anonymous 2007 May 3 3 Couldn't build 3.3.17 on Cygwin/Vista I didn't see anything quite resembling this on a cursory scan thru the buglist; pardon my goof if it's a duplicate. When I tried to build on Cygwin on Vista, things got to the install phase, and then the Makefile tried to execute cc sqlite3.c -o sqlite3 which didn't appear to be a defined rule in the Makefile. This then failed because of a lack of a main program, and the install failed. After a quick scan through the Makefile, I decided to change the target for the install rule to install: sqlite3$(TEXE) libsqlite3.la sqlite3.h ${HAVE_TCL:1=tcl_install} which seemed to remedy the problem. Suggested fix: modify Makefile as shown above. _2007-May-23 14:29:20 by anonymous:_ {linebreak} Another vote for this
#f2dcdc 2376 code active 2007 May anonymous 2007 May 3 3 -batch doesn't work soon enough on Microsoft XP, given any.db and a batch file bug.bat containing sqlite3 -batch -init bug.rc any.db "select 1;" and bug.rc containing .mode column Running bug.bat gives the message "Loading resources from bug.rc" I put in "-batch" so that the "Loading..." message would be suppressed, but it printed anyway.
#e8e8bd 2207 new active 2007 Jan anonymous 2007 May 3 4 "CREATE TABLE foo AS SELECT * FROM bar" doesn't copy constraints (cut & paste from an email I sent to the list, though afaict it never appeared) When creating a table using AS SELECT ... I noticed it didn't copy the constraints: SQLite version 3.3.8 Enter ".help" for instructions sqlite> .schema CREATE TABLE bar ( t INTEGER NOT NULL PRIMARY KEY, d INTEGER NOT NULL ); sqlite> CREATE TABLE foo AS SELECT * FROM bar; sqlite> .schema CREATE TABLE foo(timestamp INTEGER,download INTEGER); CREATE TABLE bar ( t INTEGER NOT NULL PRIMARY KEY, d INTEGER NOT NULL ); Is this expected behavior? I find myself in a sitation where ideally I would like this to create a table copying contraints (so I can do some processing in dynamically created temporary tables). I had a quick look over the documentation and it doesn't mention this either way. _2007-Jan-30 18:52:49 by drh:_ {linebreak} I have a lot of code that depends "CREATE TABLE ... AS SELECT" not copying the constraints. Changing this so that constraints are copied would break my code - which is something I am disinclined to do. ---- _2007-Jan-30 19:06:34 by anonymous:_ {linebreak} Can we perhaps just document this then as the intended behavior then then close this bug out please? ---- _2007-Jan-30 21:57:10 by anonymous:_ {linebreak} How about a new feature: CREATE TABLE foo *WITH CONSTRAINTS* AS SELECT * FROM bar
#f2dcdc 2340 code active 2007 May anonymous 2007 May 3 3 "./configure && make testfixture" link problem Until the (extremely welcome) sqlite3 blob I/O functionality was checked in, it was possible to run this command on a clean source tree: ./configure && make testfixture But it now produces these unresolved externals: ./src/tclsqlite.c:297: warning: excess elements in struct initializer ./src/tclsqlite.c:297: warning: (near initialization for `IncrblobChannelType') /tmp/ccmyzR97.o: In function `test_blob_read': /sqlite/cvs/sqlite/./src/test1.c:1545: undefined reference to `_sqlite3_blob_read' /tmp/ccmyzR97.o: In function `test_blob_write': /sqlite/cvs/sqlite/./src/test1.c:1592: undefined reference to `_sqlite3_blob_write' /tmp/ccb5dcDK.o: In function `incrblobClose': /sqlite/cvs/sqlite/./src/tclsqlite.c:156: undefined reference to `_sqlite3_blob_close' /tmp/ccb5dcDK.o: In function `incrblobInput': /sqlite/cvs/sqlite/./src/tclsqlite.c:194: undefined reference to `_sqlite3_blob_bytes' /sqlite/cvs/sqlite/./src/tclsqlite.c:202: undefined reference to `_sqlite3_blob_read' /tmp/ccb5dcDK.o: In function `incrblobOutput': /sqlite/cvs/sqlite/./src/tclsqlite.c:226: undefined reference to `_sqlite3_blob_bytes' /sqlite/cvs/sqlite/./src/tclsqlite.c:235: undefined reference to `_sqlite3_blob_write' /tmp/ccb5dcDK.o: In function `incrblobSeek': /sqlite/cvs/sqlite/./src/tclsqlite.c:264: undefined reference to `_sqlite3_blob_bytes' /tmp/ccb5dcDK.o: In function `DbObjCmd': /sqlite/cvs/sqlite/./src/tclsqlite.c:322: undefined reference to `_sqlite3_blob_open' collect2: ld returned 1 exit status make: *** [testfixture.exe] Error 1 The 2 warnings related to src/tclsqlite.c:297 also seem to indicate a problem. I'm using Tcl 8.4. _2007-May-06 21:16:01 by anonymous:_ {linebreak} Workaround - hack the generated Makefile to use: # Compiler options needed for programs that use the TCL library. # TCC += -I/usr/local/include -DSQLITE_OMIT_INCRBLOB=1
#f2dcdc 2282 code active 2007 Apr anonymous 2007 Apr 3 4 Update on view with no matching trigger does not raise error Attempting to update a view with no triggers properly fails with the error sqlite> update foo set key=key+1; SQL error: cannot modify foo because it is a view However, if a single trigger is added that contains a WHEN clause, then UPDATE statements that do not satisfy that WHEN clause silently succeed without raising any error. sqlite> select 'Before:'; select * from foo; update foo set key=key+1; select 'After:'; select * from foo; Before: 1|42|forty-two|42.0 2|69|sixty-nine|69.0 After: 1|42|forty-two|42.0 2|69|sixty-nine|69.0 _2007-Apr-18 21:50:00 by anonymous:_ {linebreak} Your desired behavior can be accomplished by changing your trigger to: create trigger foo_update instead of update on foo begin select raise(ABORT, 'invalid key') where old.key <> new.key; update foo_backing set num=new.num, str=new.str, float=new.float, dirty=1 where key=new.key; end; ---- _2007-Apr-24 20:26:46 by anonymous:_ {linebreak} I have come up with a sample patch that *partially* fixes this problem -- specifically, it raises an error if any rows affected by an update/delete against a view are not caught by any triggers. It does not handle uncaught inserts, however, because I couldn't quite figure out how to make that work (much of the logic for updates and deletes is almost identical, whereas the code for inserts is quite different.) This patch adds/updates 76 lines across 4 files. I disclaim all copyright to these 76 lines.
#e8e8bd 2313 build active 2007 Apr anonymous 2007 Apr 3 3 readline.h is not properly detected This is actually an old issue i also had with 2.8.15. configure says "checking for readline.h... no", but it really needs to look for readline/readline.h (or both?) this is easily fixed with "--with-readline-inc=-I/path/to/include" although the actual syntax for this is a bit unusual/unintuitive) but such "fix" should not be needed as i had these in my environment: CPPFLAGS="-I/path/to/include" CFLAGS="-I/path/to/include" (The library was found by configure, thanks to my LDFLAGS environment setting which is similar to the above.)
#f2dcdc 2297 code active 2007 Apr anonymous 2007 Apr 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'.
#e8e8bd 2270 build active 2007 Mar anonymous 2007 Mar 3 4 Build on Solaris 8 does not include other libs in .so build Straightforward build on solaris: # uname -a SunOS ganga 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Blade-1000 # ../sqlite-3.3.13/configure --enable-gcc # ../../tcl/8.4.14/bin/tclsh8.4 % load ./.libs/libtclsqlite3.so.0.8.6 couldn't load file "./.libs/libtclsqlite3.so.0.8.6": ld.so.1: ../../tcl/8.4.14/bin/tclsh8.4: fatal: relocation error: file ./.libs/libtclsqlite3.so.0.8.6: symbol fdatasync: referenced symbol not found Just rerun gcc for the libtclsqlite with the same options as what libtool printed and add the fdatasync library that configure found (which was -lrt): % exec gcc all-like-libtool -lrt % load ./.libs/libtclsqlite3.so.0.8.6 % I don't know why the build calls the library .0.8.6 - but that's not holding me up - I just rename it to 3.so.3.13 _2007-Mar-30 05:36:59 by anonymous:_ {linebreak} #1802, #2041 and #2270 are the same basic issue: librt should get linked into libsqlite3.so
#f2dcdc 2241 code active 2007 Feb scouten 2007 Mar 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?
#e8e8bd 2266 new active 2007 Mar anonymous 2007 Mar anonymous 3 3 Add support for Row_Number() Over Row_Number() Over is a windowing function included in the SQL:2003 standard. I need it to be able to rank order several groups by size, using a single query. I know SQLite does not support SQL:2003, but it would be nice to have at least this one function supported. _2007-Mar-10 10:06:33 by anonymous:_ {linebreak} You can easily write your own UDF using SQLite API. Here's an example if you need it right now:
typedef unsigned long long int rowNumberContext;
// aggregate step callback
void rowNumberStep(sqlite3_context *context, int argc, sqlite3_value **argv) {
// initialize or get aggregate function context
rowNumberContext *agg_context = (rowNumberContext*)sqlite3_aggregate_context(context, sizeof(rowNumberContext));
(*agg_context)++;
}
// aggregate final callback
void rowNumberFinal(sqlite3_context *context) {
sqlite3_result_int64(context, *((rowNumberContext *)sqlite3_aggregate_context(context, sizeof(rowNumberContext))));
}
// then just create function:
sqlite3_create_function(db_handle, "row_number", 0, SQLITE_ANY, null, null, rowNumberStep, rowNumberFinal);
I hope I get it right. This piece of sample code has *NOT* been tested! Use it at your own risk. ----------- The code above is a good implementation of count(*), but not row_number(). I think Row_Number() is one of the SQL2003 windowing functions. Implementing these would require modifications to the parser, compiler and vdbe layers of sqlite. Not possible using current APIs. At the current time queries that use Row_Number() will have to be rewritten to use temp tables as intermediate steps.
#e8e8bd 2247 doc active 2007 Feb anonymous 2007 Feb 3 3 documentation of DEFUALT cluase in CREATE TABLE should be fixed The documentation for the CREATE TABLE statement at http://www.sqlite.org/lang_createtable.html shows the syntax of the DEFAULT clause as DEFAULT value and the description says that value can be NULL, a string constant, a number, or one of three keyword values; CURRENT_DATE, CURRENT_TIME, or CURRENT_TIMESTAMP. This is incorrect since the DEFAULT clause also allows value to be an expression in brackets. The syntax should be changed to something like DEFAULT default_value default_value := value | ( expression ) and the description should say that some expressions are allowed. In particular functions can be used as the expression. It should also be clarified when the DEFAULT clause functions are evaluated, at the time the create statement executes, or at the time a record is added to the table. Note that not all expressions are allowed. In particular the ( select_statement ) form produces an error saying the default value is not constant, even though the apparently non-constant function random() is accepted. sqlite> create table t2(id, b default ((select avg(a) from t1))); SQL error: default value of column [b] is not constant sqlite> create table t2(id, b default (random())); sqlite> Tests using a default function julianday('now') as a default show that the function is evaluated at the time the record is inserted. If that is the case, why can the select expression above not be evaluated each time a record is inserted to generate a default value?
#f2dcdc 2075 code active 2006 Nov anonymous 2007 Feb 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 2221 new active 2007 Feb anonymous 2007 Feb drh 3 4 Store blobs using inode-like lookup of pages rather than linked list In a recent conversation, the matter of how BLOBs are stored came up. Currently, each page of BLOB data is in a linked list. By default each page is 1K so a very large BLOB may have many many pages. The linked list becomes inefficient to find and update BLOBs. DRH mentioned a thought to move to an inode style of page management for BLOBs. This would require updating the file format.
#f2dcdc 2218 code active 2007 Feb anonymous 2007 Feb 3 4 select columns from views with table prefix I have a table and a view on the table, defined like this: create table mytable (mycolumn varchar); create view myview as select mytable.mycolumn from mytable; Now select "mycolumn" from myview; does work, but select mycolumn from myview; gives "unknown column"!
#e8e8bd 2187 todo active 2007 Jan anonymous 2007 Jan 3 4 RAISE in trigger not being caught by CONFLICT clause in calling SQL When an exception is raised within a trigger, the on conflict clause on the calling SQL statement is not being invoked. Note: The CASE statement in example is to demonstrate the error, a CHECK Constraint would have been more appropriate if this were a real world senario. Sample SQL Below: ------------------------------------- CREATE TABLE abc (a);{linebreak} CREATE TRIGGER abc_insert BEFORE INSERT ON abc BEGIN{linebreak} SELECT CASE WHEN (new.a > 2) THEN{linebreak} RAISE(ABORT, 'error here'){linebreak} END;{linebreak} END;{linebreak} BEGIN;{linebreak} INSERT INTO abc VALUES (1);{linebreak} -- This should raise error but not rollback{linebreak} INSERT INTO abc VALUES (4);{linebreak} -- This should raise error and rollback{linebreak} INSERT OR ROLLBACK INTO abc VALUES (4);{linebreak} -- Check to see if ROLLBACK performed (which it hasn't){linebreak} SELECT * FROM abc;{linebreak}
#f2dcdc 2140 code active 2007 Jan anonymous 2007 Jan 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
#f2dcdc 2132 code active 2006 Dec anonymous 2006 Dec 3 4 table_info, index_list, index_info & friends should be virtual tables The following meta data should be accessible via read-only virtual tables in some sort of sqlite_meta_info table: PRAGMA database_list; PRAGMA foreign_key_list(table-name); PRAGMA index_info(index-name); PRAGMA index_list(table-name); PRAGMA table_info(table-name); This would allow complex querying and joins of the meta data of the database. (Pragmas cannot be used as a subquery). The underlying introspection mechanism can actually be PRAGMA-based for backwards compatability.
#f2dcdc 2126 code active 2006 Dec anonymous 2006 Dec 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.
#e8e8bd 2099 doc active 2006 Dec anonymous 2006 Dec 3 3 virtual table xDestroy/xDisconnect and cleanups It isn't clear what happens if xDisconnect or xDestroy return an error. From the code for sqlite3VtabCallDestroy pTab->pVtab is not set to zero. Does that mean that Destroy/Disconnect can be called again (the table has been dropped so I don't see how)? If not, then the memory is table is memory leaked. In my Python wrapper I have to decide what to do when the Python code returns an error. Should I free the Python objects when returning the error code, or leave them allocated. If they are left allocated, then will they be leaked or will there be another opportunity to free them? _2006-Dec-24 11:16:56 by anonymous:_ {linebreak} From the code, the return code from xDisconnect is completely ignored (vtab.c:62) xDisconnect is also unconditionally called whereas xDestroy is optionally called (vtab.c:496). If anything I would expect xDisconnect to be optional and xDestroy to be mandatory. I still can't answer the original question in this ticket. Currently xDisconnect ignores the return value and therefore results in unconditional disconnection. xDestroy is ultimately called in OP_VDestroy in the vdbe but I can't tell what happens if an error is returned.
#f2dcdc 2096 code active 2006 Dec anonymous 2006 Dec 3 3 ATTACH DATABASE returns SQLITE_ERROR when database is locked From an email sent to DRH: I am working on a problem surrounding the inability to ATTACH to a database file. The error text being returned is "database is locked", which should be SQLITE_BUSY, however, the error code being returned by sqlite3_exec is SQLITE_ERROR. Is sqlite3_exec wrong in returning SQLITE_ERROR rather than SQLITE_BUSY? I have some nagging feeling that I determined or read that the attachFunc function does not return a truly-relevant status code, but I can't see why offhand nor can I find any evidence to support that theory. If sqlite3_exec is doing the right thing, however, then the question becomes one of identifying when to retry the ATTACH statement; we're currently keying off SQLITE_BUSY or SQLITE_LOCKED, as appropriate, and I'd rather not be trying to trap errors based on error text.
#e8e8bd 2087 new active 2006 Nov anonymous 2006 Nov 3 3 Ability to add a check constraint via the alter table command *This is an improvement request*. Add the possibility to add a check constraint to an existing table via the alter table statement. Example : CREATE TABLE a(x INTEGER, y INTEGER); INSERT INTO a VALUES (1,2); ALTER TABLE a ADD CHECK (y>0); Actual result : SQL error: near "CHECK": syntax error
#f2dcdc 2089 code active 2006 Nov anonymous 2006 Nov 3 3 Decouple sqlite_int64 from other 64bit datatypes Currently sqlite3 makes the (valid) assumption that sqlite_int64 (or i64, u64) is 64 bit wide, matches with Tcl_WideInt and has the same datasize (and byte order) than double. The following patch fixes this and allows sqlite_int64 to be any integral type, e.g. a 32bit int (with the limitations of the reduced datatype size). The use case for this is for systems that do not support 64bit integers (e.g. lack of compiler feature, embedded system), db's of small data size, and systems without large file support. The patch allows compiling with -DSQLITE_INT64_TYPE=int -DSQLITE_32BIT_ROWID for such a system. _2006-Nov-29 01:13:07 by anonymous:_ {linebreak} Hm, now I wanted to add the patch file but I don't get the formatting right without editing the file and removing empty lines. How am I supposed to add a patch file (created with diff -ru)?
#f2dcdc 2082 code active 2006 Nov anonymous 2006 Nov 3 4 UNIX: configure script doesn't enable loading of extensions The code in loadext.c:234 looks for HAVE_DLOPEN being #defined in order to enable library loading on Linux. However as best I can tell, the configure script never looks for dlopen. It does look for dlfcn.h. (Based on examining the output of configure and config.log) Consequently extension loading isn't available on Unixen that do support it if you build using ./configure Work around is to use this commmand: env CFLAGS="-DHAVE_DLOPEN" ./configure _2006-Nov-26 20:53:59 by drh:_ {linebreak} The "autoconf" command is busted in SuSE 10.2, which is the OS I am currently running. So I am unable to rebuild configure after editing configure.ac. Until the autoconf problem is resolved, I am unable to address the request in this ticket. Sorry. ---- _2006-Nov-26 22:36:48 by anonymous:_ {linebreak} What happens when you upgrade to the latest version of autoconf for SuSE? I'm sure someone on the list could help you resolve this issue. ---- _2006-Nov-27 07:05:27 by anonymous:_ {linebreak} I am actually using Gentoo. There is a trivial workaround as I noted so there is no need for a solution for 3.3.8. It would be nice to have it fixed for whatever version comes next so that I don't need to document the workaround. ---- _2006-Nov-27 18:32:11 by anonymous:_ {linebreak} Another open autoconf ticket: Check-in [3397] : Add HAVE_GMTIME_R and HAVE_LOCALTIME_R flags and use them if defined. Unable to modify the configure script to test for gmtime_r and localtime_r, however, because on my SuSE 10.2 system, autoconf generates a configure script that does not work. Bummer. Ticket #1906
#f2dcdc 2057 code active 2006 Nov anonymous 2006 Nov 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.
#f2dcdc 2011 code active 2006 Oct anonymous 2006 Oct 3 2 Escaping Porblem with .mode insert (double apostrophe) select * from messages where message_id="74B23AAF-5FFD6BF2"; 74B23AAF-5FFD6BF2|75|0|0|0|0|Europe talks, acts tough on Iran||http://www.ncr-iran.org/index.php?option=com_content&task=view&id=1052&Itemid=71|1140529235.0|By Gareth HardingThe United Press International, BRUSSELS -- Europeans are supposed to prefer soft to hard power, jaw-jaw to war-war and appeasement to confrontation. In short, in the words of neo-conservative scholar Robert Kagan: \'Americans are from Mars; Europeans are from Venus.\' The ".mode insert / .output" file looks like this. INSERT INTO messages VALUES('74B23AAF-5FFD6BF2',75,0,0,0,0,'Europe talks, acts tough on Iran','','http://www.ncr-iran.org/index.php?option=com_content&task=view&id=1052&Itemid=71',1140529235.0,'By Gareth HardingThe United Press International, BRUSSELS -- Europeans are supposed to prefer soft to hard power, jaw-jaw to war-war and appeasement to confrontation. In short, in the words of neo-conservative scholar Robert Kagan: \''Americans are from Mars; Europeans are from Venus.\'''); Now there are two apostrophe and the Escaping is broken.
#f2dcdc 2010 code active 2006 Oct anonymous 2006 Oct 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 1822 code active 2006 May anonymous 2006 Sep 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 1445 code active 2005 Sep anonymous 2006 Sep 3 3 Errors testing sqlite 3.2.6 (& v3.3.7) $ make test [...] conflict-6.0... Ok conflict-6.1... Ok conflict-6.2... Expected: [0 {7 6 9} 1 1] Got: [0 {7 6 9} 1 0] conflict-6.3... Expected: [0 {6 7 3 9} 1 1] Got: [0 {6 7 3 9} 1 0] conflict-6.4... Ok conflict-6.5... Ok conflict-6.6... Ok conflict-6.7... Expected: [0 {6 7 3 9} 1 1] Got: [0 {6 7 3 9} 1 0] conflict-6.8... Expected: [0 {7 6 9} 1 1] Got: [0 {7 6 9} 1 0] conflict-6.9... Expected: [0 {6 7 3 9} 1 1] Got: [0 {6 7 3 9} 1 0] conflict-6.10... Expected: [0 {7 6 9} 1 1] Got: [0 {7 6 9} 1 0] conflict-6.11... Expected: [0 {6 7 3 9} 1 1] Got: [0 {6 7 3 9} 1 0] conflict-6.12... Expected: [0 {6 7 3 9} 1 1] Got: [0 {6 7 3 9} 1 0] conflict-6.13... Expected: [0 {7 6 9} 1 1] Got: [0 {7 6 9} 1 0] conflict-6.14... Ok conflict-6.15... Ok conflict-6.16... Ok [...] date-3.12... Ok date-3.13... Ok date-3.14... Ok date-3.15... Ok date-3.16... Ok date-3.17... Ok /tmp/sqlite-3.2.6/.libs/lt-testfixture: invalid command name "clock" while executing "clock seconds" invoked from within "clock format [clock seconds] -format "%Y-%m-%d" -gmt 1" invoked from within "set now [clock format [clock seconds] -format "%Y-%m-%d" -gmt 1]" (file "./test/date.test" line 142) invoked from within "source $testfile" ("foreach" body line 4) invoked from within "foreach testfile [lsort -dictionary [glob $testdir/*.test]] { set tail [file tail $testfile] if {[lsearch -exact $EXCLUDE $tail]>=0} continue so..." (file "./test/quick.test" line 45) make: *** [test] Error 1 _2005-Sep-19 23:03:56 by drh:_ {linebreak} The test scripts do not (yet) work with Tcl 8.5. Use Tcl 8.4. ---- _2005-Sep-20 01:59:42 by anonymous:_ {linebreak} FYI, The conflict failures occur even when using tcl-8.4. The problem was reported on the mailing list: http://www.mail-archive.com/sqlite-users%40sqlite.org/msg10203.html Curiously, the failures correspond exactly to the test cases that were changed by the following patch: http://www.sqlite.org/cvstrac/filediff?f=sqlite/test/conflict.test&v1=1.24&v2=1.25 ---- _2006-Aug-31 23:49:40 by anonymous:_ {linebreak} building v337 on OSX 10.4.7 w/ TCL8.5 installed as Framework, 'make test' still fails w/: date-3.16... Ok date-3.17... Ok /usr/ports/sqlite-3.3.7/build/.libs/testfixture: invalid command name "clock" while executing "clock seconds" invoked from within "clock format [clock seconds] -format "%Y-%m-%d" -gmt 1" invoked from within "set now [clock format [clock seconds] -format "%Y-%m-%d" -gmt 1]" (file "../test/date.test" line 142) invoked from within "source $testfile" ("foreach" body line 4) invoked from within "foreach testfile [lsort -dictionary [glob $testdir/*.test]] { set tail [file tail $testfile] if {[lsearch -exact $EXCLUDE $tail]>=0} continue so..." (file "../test/quick.test" line 66) make: *** [test] Error 1 any resolution for this, other than revert to TCL 8.4? ---- _2006-Sep-01 01:26:37 by anonymous:_ {linebreak} SQLite under Cygwin fails all tests that involve integers larger than 32 bits. Sqlite produces the correct 64 bit values, but Tcl as distributed with Cygwin cannot grok 64 bit ints, so the comparisons fail. Would it be possible to change Sqlite's test harness to compare SQL results as strings rather than as integers? Then it would not matter if Tcl worked in 64 bit or not. ---- _2006-Sep-01 15:50:48 by drh:_ {linebreak} The test suite has been revised so that it now works with Tcl8.5. But, no, it is not practical to rewrite the tests to compare the results using strings instead of integers in order to work with the (broken) tcl implementation that comes with cygwin. ---- _2006-Sep-06 02:39:24 by anonymous:_ updating to latest cvs-checkout to get the aforementioned fix for: date-3.17... Ok /usr/ports/sqlite-3.3.7/build/.libs/testfixture: invalid command name "clock" while executing i can verify that _that_ is now ok: ... date-3.14... Ok date-3.15... Ok date-3.16... Ok date-3.17... Ok date-4.1... Expected: [2006-09-01] Got: [2006-09-06] date-5.1... Ok date-5.2... Ok date-5.3... Ok ... but now, 'make test' fails next @: delete-8.4... Ok delete-8.5... Ok delete-8.6... Ok delete-8.7... Ok /usr/ports/sqlite-cvs/build/.libs/testfixture: error deleting "test.db": not owner while executing "file delete -force test.db" (file "../test/tester.tcl" line 62) invoked from within "source $testdir/tester.tcl" (file "../test/delete2.test" line 36) invoked from within "source $testfile" ("foreach" body line 4) invoked from within "foreach testfile [lsort -dictionary [glob $testdir/*.test]] { set tail [file tail $testfile] if {[lsearch -exact $EXCLUDE $tail]>=0} continue so..." (file "../test/quick.test" line 66) make: *** [test] Error 1 ---- _2006-Sep-06 11:11:19 by drh:_ {linebreak} Run the build starting from an empty directory as a non-root user. ---- _2006-Sep-06 13:27:18 by anonymous:_ {linebreak} per INSTALL instructions, i did: cvs -d :pserver:anonymous@www.sqlite.org:/sqlite checkout -d sqlite-cvs sqlite cd /usr/ports/sqlite-cvs mkdir build cd build ../configure \ ... make chown -R myuser:wheel /usr/ports/sqlite-cvs sudo -u myuser make test and, as reported, the error was the result. ---- _2006-Sep-30 21:43:45 by anonymous:_ {linebreak} bump. anyone? ---- _2006-Sep-30 22:19:24 by anonymous:_ {linebreak} If you don't happen to be testing on Linux/gcc or Windows/VC++ I find that the Tcl test results have more than a few failures. It is not always easy to discern which failures are due to some odd quirk of Tcl or whether it is a legitimate SQLite issue on a given platform. Be prepared to change test scripts and tinker with the code.
#e8e8bd 1961 build active 2006 Sep anonymous 2006 Sep 3 3 3.3.7 : wrong readline.h path in Makefile We have readline.h installed in /usr/local/include/readline. In SQLite it is accessed with : #include But unfortunatly in Makefile, READLINE flags contains : -I /usr/local/include/readline instead of -I /usr/local/include
#f2dcdc 1947 code active 2006 Aug anonymous Shell 2006 Aug 3 3 ".mode insert" works bad with BLOBs .mode insert displays BLOBs as strings, which isn't very good for embedded NULs. Having output more like the one from .dump would be better, IMO. sqlite> select * from t; INSERT INTO table VALUES(''); sqlite> .dump BEGIN TRANSACTION; CREATE TABLE t(f BLOB); INSERT INTO "t" VALUES(X'0041'); COMMIT;
#f2dcdc 518 code active 2003 Dec anonymous Unknown 2006 Aug 3 4 PRIMARY KEY does not imply UNIQUE and NOT NULL According to SQL92 and Dr. Hipp, PRIMARY KEY should imply both NOT NULL and UNIQUE. It does not. The following statements exhibit the problem: CREATE TABLE User ( Name VARCHAR (40), UID INTEGER, DeviceID VARCHAR (64), PRIMARY KEY (Name, UID, DeviceID) ); INSERT INTO User (Name,DeviceID) VALUES ('Michael','Test'); INSERT INTO User (Name,DeviceID) VALUES ('Michael','Test'); Gets me two rows with ('Michael',NULL,'Test'). _2005-Jan-03 01:46:01 by drh:_ {linebreak} See http://www.sqlite.org/nulls.html. SQLite considers NULLs to be distinct. PostgreSQL, Oracle, MySQL, and Firebird all work this way. Informix and MS-SQL work differently. Works as designed. ---- _2006-Aug-26 07:29:58 by anonymous:_ {linebreak} as far as I can see, the closing remark applies to the UNIQUEness of NULL values, not the NOT NULLness of PRIMARY KEYs (or part of that). let's see what some engines do: PostgreSQL: biblioteca=> CREATE TABLE test ( Name VARCHAR (40), UID INTEGER, DeviceID VARCHAR (64), PRIMARY KEY (Name, UID, DeviceID) ); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey" for table "test" CREATE TABLE biblioteca=> insert into test(Name, DeviceID) values ('Michael', 'test'); ERROR: null value in column "uid" violates not-null constraint
MySQL: mysql> CREATE TABLE test ( Name VARCHAR (40), UID INTEGER, DeviceID VARCHAR (64), PRIMARY KEY (Name, UID, DeviceID) ); Query OK, 0 rows affected (0.07 sec) mysql> insert into test(Name, DeviceID) values ('Michael', 'test'); Query OK, 1 row affected (0.11 sec) mysql> insert into test(Name, DeviceID) values ('Michael', 'test'); ERROR 1062 (23000): Duplicate entry 'Michael-0-test' for key 1
that is: it MySQL is also not allowing NULL primary keys and is silently replacing NULL values with 0. Oracle: CREATE TABLE test ( Name VARCHAR (40), UniqueID INTEGER, DeviceID VARCHAR (64), PRIMARY KEY (Name, UniqueID, DeviceID) ); insert into test(Name, DeviceID) values ('Michael', 'test'); ORA-01400: impossibile inserire NULL in ("IBOTEST"."TEST"."UNIQUEID")
I hope no-one will disagree if I reopen the ticket. ---- _2006-Aug-29 11:51:00 by anonymous:_ {linebreak} behaviour with the patch: sqlite> CREATE TABLE User ( Name VARCHAR (40), ...> UID INTEGER, ...> DeviceID VARCHAR (64), ...> PRIMARY KEY (Name, UID, DeviceID) ); sqlite> INSERT INTO User (Name,DeviceID) VALUES ('Michael','Test'); SQL error: User.UID may not be NULL sqlite> INSERT INTO User (Name,DeviceID) VALUES ('Michael','Test'); SQL error: User.UID may not be NULL ---- _2006-Aug-29 13:10:37 by drh:_ {linebreak} To my great surprise, I discovered that SQLite has allowed NULL values in PRIMARY KEY columns for a very long time. This is a bug. But the bug has been in the code for so long, that we fear fixing it might break legacy applications. So for now we have chosen to merely document the fact that the bug exists and to warn developers not to depend on it since it might be fixed at some unspecified point in the future. ---- _2006-Aug-29 19:54:12 by anonymous:_ {linebreak} Can you put a SQLITE_ENABLE_NOTNULL_PRIMARYKEYS #ifdef and apply this patch to the official tree? This may solve the problems with legacy code and solve the SQL issue
#f2dcdc 1893 code active 2006 Jul anonymous 2006 Aug 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 1890 code active 2006 Jul anonymous Unknown 2006 Jul 3 4 double quotes ("") in a query are ambiguous sqlite> SELECT "uuid" FROM objects LIMIT 1;{linebreak} b43c9cdc-0dc8-11db-9475-080020a846a9{linebreak} sqlite> SELECT "uuidx" FROM objects LIMIT 1;{linebreak} uuidx{linebreak} The objects table has a column named uuid; it does not have a column named uuidx. The behaviour of "" depends on whether the contents are a valid column name, and I cannot see when this is desirable behaviour. (I know that `` and '' are the right quotes to use, by the way - I'm just pointing out that "" can surprise people a lot and should probably be fixed or removed) _2006-Jul-13 13:39:37 by anonymous:_ {linebreak} The current behaviour is an SQL standard thing, so SQLite implements it for the sake of compatibility. Certainly most people agree with you that it's a bad thing. ---- _2006-Jul-13 16:56:05 by anonymous:_ {linebreak} Perhaps what we need then is a big fat warning in the manual :) - Peter ---- _2006-Jul-17 00:06:41 by drh:_ {linebreak} Please suggest a specific location in the documentation where I should put a warning about the use of " instead of ' and I will add it. ---- _2006-Jul-27 10:30:12 by anonymous:_ {linebreak} lang_expr.html seems like an obvious choice; perhaps also a sidenote on FAQ question 16 - Peter
#f2dcdc 1884 code active 2006 Jul anonymous 2006 Jul 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.
#e8e8bd 1864 new active 2006 Jun anonymous 2006 Jun drh 3 3 List availabe SQL functions Once LoadableExtensions are implemented it would be really nice to be able to get list of all available SQL functions and number[s] of arguments.{linebreak} Mostly I'm thinking about a scenario where you'd load someone else's library from SQLite shell. Hopefully those will become common once infrastructure is in place. I guess SQLite already keeps track of all available functions internally? _2006-Jun-21 19:48:07 by drh:_ {linebreak} Perhaps this could be done using a {link: wiki?p=VirtualTables virtual table}. ---- _2006-Jun-21 20:15:27 by anonymous:_ {linebreak} Yes, this seems to be a really nice fit for virtual tables. I lurked through the sources briefly, and it seems like all required info is already there, in =struct sqlite3=. Right?
#f2dcdc 1857 code active 2006 Jun anonymous 2006 Jun 3 4 Can't use ISO 8601 dates with time zone designator 'Z' Date-times of the format 'YYYY-MM-DDTHH:MM:SS.sssZ' do not return a valid date. e.g. datetime('2006-06-19T15:44:07.466940Z'). The 'Z' indicates UTC.{linebreak} This is the format generated by 'svn log --xml'. More details of the format at {link: http://www.w3.org/TR/NOTE-datetime}. This 'svn diff' fixes the problem: --- date.c (revision 656) +++ date.c (working copy) @@ -136,7 +136,7 @@ ** ** If the parse is successful, write the number of minutes ** of change in *pnMin and return 0. If a parser error occurs, -** return 0. +** return 1. ** ** A missing specifier is not considered an error. */ @@ -200,7 +200,10 @@ p->h = h; p->m = m; p->s = s + ms; - if( parseTimezone(zDate, p) ) return 1; + if (*zDate == 'Z') + p->tz = 0; + else if( parseTimezone(zDate, p) ) + return 1; p->validTZ = p->tz!=0; return 0; }
PS Should probably add a test case to 'sqlite/test/date.test'.
#f2dcdc 1853 code active 2006 Jun anonymous 2006 Jun 3 4 sqlite3_analyzer-3.3.4 integer overflows on large database sqlite3_analyzer-3.3.4 reports senseless values (negative bytes and percents) for some fields of my 28 GB database: Examples: Bytes of storage consumed............. 291456000 Bytes of payload...................... -1382746251 -474.4% Average payload per entry............. -3.80 (I'll attached the full output separatly.) I'm using the pre-built Linux binary of sqlite3_analyzer-3.3.4 from the sqlite homepage. My system is cn@jehova:~/misc/jibladze> uname -a Linux jehova 2.6.13-15.10-smp #1 SMP Fri May 12 16:11:24 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux _2006-Jun-18 17:28:20 by anonymous:_ {linebreak} Here's the full output: cn@jehova:~> du -ah /playground/cn/yacop-data/gfr/steenrod-5-E-1Rfull 28G /playground/cn/yacop-data/gfr/steenrod-5-E-1Rfull cn@jehova:~> sqlite-analyzer /playground/cn/yacop-data/gfr/steenrod-5-E-1Rfull Analyzing table chartinfo... Analyzing table complog... Analyzing table fragments... Analyzing table generators... Analyzing table header... Analyzing table sqlite_master... Analyzing table worklog... Analyzing index sdegind of table fragments... Analyzing index sqlite_autoindex_header_1 of table header... Analyzing index sqlite_autoindex_worklog_1 of table worklog... /** Disk-Space Utilization Report For /playground/cn/yacop-data/gfr/steenrod-5-E-1Rfull *** As of 2006-Jun-18 18:55:01 Page size in bytes.................... 1024 Pages in the whole file (measured).... 28439973 Pages in the whole file (calculated).. 28439972 Pages that store data................. 28439972 100.000% Pages on the freelist (per header).... 0 0.0% Pages on the freelist (calculated).... 1 0.0% Pages of auto-vacuum overhead......... 0 0.0% Number of tables in the database...... 7 Number of indices..................... 3 Number of named indices............... 1 Automatically generated indices....... 2 Size of the file in bytes............. 29122532352 Bytes of user payload stored.......... -1818729787 -6.2% *** Page counts for all tables with their indices ******************** FRAGMENTS............................. 28409448 99.89% COMPLOG............................... 13559 0.048% CHARTINFO............................. 11151 0.039% GENERATORS............................ 5797 0.020% WORKLOG............................... 10 0.0% SQLITE_MASTER......................... 5 0.0% HEADER................................ 2 0.0% *** All tables and indices ******************************************* Percentage of total database.......... 100.000% Number of entries..................... 728140955 Bytes of storage consumed............. -942239744 Bytes of payload...................... 1093495310 -116.1% Average payload per entry............. 1.50 Average unused bytes per entry........ -2.73 Average fanout........................ 88.00 Maximum payload per entry............. 1157 Entries that use overflow............. 351 0.0% Index pages used...................... 270372 Primary pages used.................... 28169249 Overflow pages used................... 351 Total pages used...................... 28439972 Unused bytes on index pages........... 32954241 11.9% Unused bytes on primary pages......... -2022053395 165.815% Unused bytes on overflow pages........ 37488 10.4% Unused bytes on all pages............. -1989061666 211.099% *** All tables ******************************************************* Percentage of total database.......... 84.3% Number of entries..................... 364670985 Bytes of storage consumed............. -1233700864 Bytes of payload...................... -1818727376 147.420% Average payload per entry............. -4.99 Average unused bytes per entry........ 4.87 Average fanout........................ 88.00 Maximum payload per entry............. 1157 Entries that use overflow............. 351 0.0% Index pages used...................... 270372 Primary pages used.................... 23690315 Overflow pages used................... 351 Total pages used...................... 23961038 Unused bytes on index pages........... 32954241 11.9% Unused bytes on primary pages......... 1742865277 -115.4% Unused bytes on overflow pages........ 37488 10.4% Unused bytes on all pages............. 1775857006 -143.9% *** All indices ****************************************************** Percentage of total database.......... 15.7% Number of entries..................... 363469970 Bytes of storage consumed............. 291461120 Bytes of payload...................... -1382744610 -474.4% Average payload per entry............. -3.80 Average unused bytes per entry........ 1.46 Maximum payload per entry............. 17 Entries that use overflow............. 0 0.0% Primary pages used.................... 4478934 Overflow pages used................... 0 Total pages used...................... 4478934 Unused bytes on primary pages......... 530048624 181.859% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 530048624 181.859% *** Table CHARTINFO ************************************************** Percentage of total database.......... 0.039% Number of entries..................... 560603 Bytes of storage consumed............. 11418624 Bytes of payload...................... 7708145 67.5% Average payload per entry............. 13.75 Average unused bytes per entry........ 0.31 Average fanout........................ 99.00 Maximum payload per entry............. 14 Entries that use overflow............. 0 0.0% Index pages used...................... 112 Primary pages used.................... 11039 Overflow pages used................... 0 Total pages used...................... 11151 Unused bytes on index pages........... 14280 12.5% Unused bytes on primary pages......... 160371 1.4% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 174651 1.5% *** Table COMPLOG **************************************************** Percentage of total database.......... 0.048% Number of entries..................... 322413 Bytes of storage consumed............. 13884416 Bytes of payload...................... 11350473 81.7% Average payload per entry............. 35.20 Average unused bytes per entry........ 1.20 Average fanout........................ 98.00 Maximum payload per entry............. 45 Entries that use overflow............. 0 0.0% Index pages used...................... 138 Primary pages used.................... 13421 Overflow pages used................... 0 Total pages used...................... 13559 Unused bytes on index pages........... 19411 13.7% Unused bytes on primary pages......... 367295 2.7% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 386706 2.8% *** Table FRAGMENTS and all its indices ****************************** Percentage of total database.......... 99.89% Number of entries..................... 726939530 Bytes of storage consumed............. -973496320 Bytes of payload...................... 1070540938 -110.0% Average payload per entry............. 1.47 Average unused bytes per entry........ -2.74 Average fanout........................ 88.00 Maximum payload per entry............. 1157 Entries that use overflow............. 351 0.0% Index pages used...................... 270061 Primary pages used.................... 28139036 Overflow pages used................... 351 Total pages used...................... 28409448 Unused bytes on index pages........... 32910337 11.9% Unused bytes on primary pages......... -2022636857 161.759% Unused bytes on overflow pages........ 37488 10.4% Unused bytes on all pages............. -1989689032 204.386% *** Table FRAGMENTS w/o any indices ********************************** Percentage of total database.......... 84.1% Number of entries..................... 363469765 Bytes of storage consumed............. -1264952320 Bytes of payload...................... -1841680107 145.593% Average payload per entry............. -5.07 Average unused bytes per entry........ 4.88 Average fanout........................ 88.00 Maximum payload per entry............. 1157 Entries that use overflow............. 351 0.0% Index pages used...................... 270061 Primary pages used.................... 23660107 Overflow pages used................... 351 Total pages used...................... 23930519 Unused bytes on index pages........... 32910337 11.9% Unused bytes on primary pages......... 1742284627 -113.0% Unused bytes on overflow pages........ 37488 10.4% Unused bytes on all pages............. 1775232452 -140.3% *** Indices of table FRAGMENTS *************************************** Percentage of total database.......... 15.7% Number of entries..................... 363469765 Bytes of storage consumed............. 291456000 Bytes of payload...................... -1382746251 -474.4% Average payload per entry............. -3.80 Average unused bytes per entry........ 1.46 Maximum payload per entry............. 9 Entries that use overflow............. 0 0.0% Primary pages used.................... 4478929 Overflow pages used................... 0 Total pages used...................... 4478929 Unused bytes on primary pages......... 530045812 181.861% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 530045812 181.861% *** Table GENERATORS ************************************************* Percentage of total database.......... 0.020% Number of entries..................... 317989 Bytes of storage consumed............. 5936128 Bytes of payload...................... 3889213 65.5% Average payload per entry............. 12.23 Average unused bytes per entry........ 0.18 Average fanout........................ 98.00 Maximum payload per entry............. 14 Entries that use overflow............. 0 0.0% Index pages used...................... 59 Primary pages used.................... 5738 Overflow pages used................... 0 Total pages used...................... 5797 Unused bytes on index pages........... 8350 13.8% Unused bytes on primary pages......... 49171 0.84% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 57521 0.97% *** Table HEADER and all its indices ********************************* Percentage of total database.......... 0.0% Number of entries..................... 10 Bytes of storage consumed............. 2048 Bytes of payload...................... 187 9.1% Average payload per entry............. 18.70 Average unused bytes per entry........ 180.70 Maximum payload per entry............. 50 Entries that use overflow............. 0 0.0% Primary pages used.................... 2 Overflow pages used................... 0 Total pages used...................... 2 Unused bytes on primary pages......... 1807 88.2% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 1807 88.2% *** Table HEADER w/o any indices ************************************* Percentage of total database.......... 0.0% Number of entries..................... 5 Bytes of storage consumed............. 1024 Bytes of payload...................... 124 12.1% Average payload per entry............. 24.80 Average unused bytes per entry........ 173.80 Maximum payload per entry............. 50 Entries that use overflow............. 0 0.0% Primary pages used.................... 1 Overflow pages used................... 0 Total pages used...................... 1 Unused bytes on primary pages......... 869 84.9% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 869 84.9% *** Indices of table HEADER ****************************************** Percentage of total database.......... 0.0% Number of entries..................... 5 Bytes of storage consumed............. 1024 Bytes of payload...................... 63 6.2% Average payload per entry............. 12.60 Average unused bytes per entry........ 187.60 Maximum payload per entry............. 17 Entries that use overflow............. 0 0.0% Primary pages used.................... 1 Overflow pages used................... 0 Total pages used...................... 1 Unused bytes on primary pages......... 938 91.6% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 938 91.6% *** Table SQLITE_MASTER ********************************************** Percentage of total database.......... 0.0% Number of entries..................... 10 Bytes of storage consumed............. 5120 Bytes of payload...................... 2411 47.1% Average payload per entry............. 241.10 Average unused bytes per entry........ 249.70 Average fanout........................ 4.00 Maximum payload per entry............. 483 Entries that use overflow............. 0 0.0% Index pages used...................... 1 Primary pages used.................... 4 Overflow pages used................... 0 Total pages used...................... 5 Unused bytes on index pages........... 891 87.0% Unused bytes on primary pages......... 1606 39.2% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 2497 48.8% *** Table WORKLOG and all its indices ******************************** Percentage of total database.......... 0.0% Number of entries..................... 400 Bytes of storage consumed............. 10240 Bytes of payload...................... 3943 38.5% Average payload per entry............. 9.86 Average unused bytes per entry........ 10.46 Average fanout........................ 5.00 Maximum payload per entry............. 13 Entries that use overflow............. 0 0.0% Index pages used...................... 1 Primary pages used.................... 9 Overflow pages used................... 0 Total pages used...................... 10 Unused bytes on index pages........... 972 94.9% Unused bytes on primary pages......... 3212 34.9% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 4184 40.9% *** Table WORKLOG w/o any indices ************************************ Percentage of total database.......... 0.0% Number of entries..................... 200 Bytes of storage consumed............. 6144 Bytes of payload...................... 2365 38.5% Average payload per entry............. 11.82 Average unused bytes per entry........ 11.55 Average fanout........................ 5.00 Maximum payload per entry............. 13 Entries that use overflow............. 0 0.0% Index pages used...................... 1 Primary pages used.................... 5 Overflow pages used................... 0 Total pages used...................... 6 Unused bytes on index pages........... 972 94.9% Unused bytes on primary pages......... 1338 26.1% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 2310 37.6% *** Indices of table WORKLOG ***************************************** Percentage of total database.......... 0.0% Number of entries..................... 200 Bytes of storage consumed............. 4096 Bytes of payload...................... 1578 38.5% Average payload per entry............. 7.89 Average unused bytes per entry........ 9.37 Maximum payload per entry............. 9 Entries that use overflow............. 0 0.0% Primary pages used.................... 4 Overflow pages used................... 0 Total pages used...................... 4 Unused bytes on primary pages......... 1874 45.8% Unused bytes on overflow pages........ 0 Unused bytes on all pages............. 1874 45.8% *** Definitions ****************************************************** Page size in bytes The number of bytes in a single page of the database file. Usually 1024. Number of pages in the whole file The number of 1024-byte pages that go into forming the complete database Pages that store data The number of pages that store data, either as primary B*Tree pages or as overflow pages. The number at the right is the data pages divided by the total number of pages in the file. Pages on the freelist The number of pages that are not currently in use but are reserved for future use. The percentage at the right is the number of freelist pages divided by the total number of pages in the file. Pages of auto-vacuum overhead The number of pages that store data used by the database to facilitate auto-vacuum. This is zero for databases that do not support auto-vacuum. Number of tables in the database The number of tables in the database, including the SQLITE_MASTER table used to store schema information. Number of indices The total number of indices in the database. Number of named indices The number of indices created using an explicit CREATE INDEX statement. Automatically generated indices The number of indices used to implement PRIMARY KEY or UNIQUE constraints on tables. Size of the file in bytes The total amount of disk space used by the entire database files. Bytes of user payload stored The total number of bytes of user payload stored in the database. The schema information in the SQLITE_MASTER table is not counted when computing this number. The percentage at the right shows the payload divided by the total file size. Percentage of total database The amount of the complete database file that is devoted to storing information described by this category. Number of entries The total number of B-Tree key/value pairs stored under this category. Bytes of storage consumed The total amount of disk space required to store all B-Tree entries under this category. The is the total number of pages used times the pages size. Bytes of payload The amount of payload stored under this category. Payload is the data part of table entries and the key part of index entries. The percentage at the right is the bytes of payload divided by the bytes of storage consumed. Average payload per entry The average amount of payload on each entry. This is just the bytes of payload divided by the number of entries. Average unused bytes per entry The average amount of free space remaining on all pages under this category on a per-entry basis. This is the number of unused bytes on all pages divided by the number of entries. Maximum payload per entry The largest payload size of any entry. Entries that use overflow The number of entries that user one or more overflow pages. Total pages used This is the number of pages used to hold all information in the current category. This is the sum of index, primary, and overflow pages. Index pages used This is the number of pages in a table B-tree that hold only key (rowid) information and no data. Primary pages used This is the number of B-tree pages that hold both key and data. Overflow pages used The total number of overflow pages used for this category. Unused bytes on index pages The total number of bytes of unused space on all index pages. The percentage at the right is the number of unused bytes divided by the total number of bytes on index pages. Unused bytes on primary pages The total number of bytes of unused space on all primary pages. The percentage at the right is the number of unused bytes divided by the total number of bytes on primary pages. Unused bytes on overflow pages The total number of bytes of unused space on all overflow pages. The percentage at the right is the number of unused bytes divided by the total number of bytes on overflow pages. Unused bytes on all pages The total number of bytes of unused space on all primary and overflow pages. The percentage at the right is the number of unused bytes divided by the total number of bytes. ********************************************************************** The entire text of this report can be sourced into any SQL database engine for further analysis. All of the text above is an SQL comment. The data used to generate this report follows: */ BEGIN; CREATE TABLE space_used( name clob, -- Name of a table or index in the database file tblname clob, -- Name of associated table is_index boolean, -- TRUE if it is an index, false for a table nentry int, -- Number of entries in the BTree leaf_entries int, -- Number of leaf entries payload int, -- Total amount of data stored in this table or index ovfl_payload int, -- Total amount of data stored on overflow pages ovfl_cnt int, -- Number of entries that use overflow mx_payload int, -- Maximum payload size int_pages int, -- Number of interior pages used leaf_pages int, -- Number of leaf pages used ovfl_pages int, -- Number of overflow pages used int_unused int, -- Number of unused bytes on interior pages leaf_unused int, -- Number of unused bytes on primary pages ovfl_unused int -- Number of unused bytes on overflow pages ); INSERT INTO space_used VALUES('chartinfo','chartinfo',0,571641,560603,7708145,0,0,14,112,11039,0,14280,160371,0); INSERT INTO space_used VALUES('complog','complog',0,335833,322413,11350473,0,0,45,138,13421,0,19411,367295,0); INSERT INTO space_used VALUES('fragments','fragments',0,387129871,363469765,19633156373,320532,351,1157,270061,23660107,351,32910337,1742284627,37488); INSERT INTO space_used VALUES('generators','generators',0,323726,317989,3889213,0,0,14,59,5738,0,8350,49171,0); INSERT INTO space_used VALUES('header','header',0,5,5,124,0,0,50,0,1,0,0,869,0); INSERT INTO space_used VALUES('sqlite_master','sqlite_master',0,13,10,2411,0,0,483,1,4,0,891,1606,0); INSERT INTO space_used VALUES('worklog','worklog',0,204,200,2365,0,0,13,1,5,0,972,1338,0); INSERT INTO space_used VALUES('sdegind','fragments',1,363469765,363469765,2912221045,0,0,9,0,4478929,0,0,530045812,0); INSERT INTO space_used VALUES('sqlite_autoindex_header_1','header',1,5,5,63,0,0,17,0,1,0,0,938,0); INSERT INTO space_used VALUES('sqlite_autoindex_worklog_1','worklog',1,200,200,1578,0,0,9,0,4,0,0,1874,0); COMMIT;
#f2dcdc 1815 code active 2006 May anonymous Parser 2006 May 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
#e8e8bd 1814 new active 2006 May anonymous 2006 May 3 4 Autoconf support for MacOSX univeral binaries SQLite is used widely on OS X. One problem for many OS X developers is preparing SQLite for universal binaries. I think there are a couple ways to solve this. 1. Add a new configure option --enable-macosx-universal to put the right compiler switches 2. Rework the configure makefiles so that you can override with the typical CFLAGS overrides as suggested by Apple in this article: http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/compiling/chapter_4_section_3.html I've attached a patch that will enable universal binaries if you chose the --enable-macosx-universal option, are on *-*-darwin* os, and have disabled shared libraries. This patch may not be exactly how you would want to integrate but it should serve as a good starting point. I've tested in a PPC powermac, PPC powerbook, and Intel Mac mini. ---- --- sqlite-3.3.5/configure.ac 2006-04-03 13:16:01.000000000 -0700
+++ sqlite-3.3.x/configure.ac 2006-05-18 16:42:08.000000000 -0700
@@ -661,6 +661,32 @@
AC_CHECK_FUNC(fdatasync, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_FDATASYNC=1"])
+##########
+# Mac OS X Universal Binary support
+#
+AC_MSG_CHECKING([whether building for macosx])
+case "${build}" in
+ *-*-darwin* )
+ AC_ARG_ENABLE(macosx-universal,
+ AC_HELP_STRING([--enable-macosx-universal],[Enable macosx universal binaries]),,enable_macosxuniversal=no)
+ AC_MSG_CHECKING([whether building Universal Binaries])
+ if test "$enable_macosxuniversal" = "no"; then
+ AC_MSG_RESULT([no])
+ else
+ AC_MSG_CHECKING([if shared libraries are disabled])
+ if test "$enable_shared" = "no"; then
+ TARGET_CFLAGS="$TARGET_CFLAGS -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk"
+ AC_MSG_RESULT([yes (Universal Binaries enabled)])
+ else
+ AC_MSG_RESULT([no (Universal Binaries disabled)])
+ fi
+ fi
+ ;;
+ *)
+ AC_MSG_RESULT([no])
+esac
+
+
#########
# Put out accumulated miscellaneous LIBRARIES
#
----
#e8e8bd 1810 new active 2006 May anonymous 2006 May 3 3 localtime() not threadsafe on UNIX The following SQLite code from src/date.c is only guaranteed to function correctly with multiple threads on UNIX if the SQLite library is the only caller of localtime(). If an application that uses the SQLite library's date functions happens to call localtime() either directly or indirectly via another third party library, then localtime() can return a pointer to inconsistant data. localtime_r() should be use instead. sqlite3OsEnterMutex(); pTm = localtime(&t); y.Y = pTm->tm_year + 1900; y.M = pTm->tm_mon + 1; y.D = pTm->tm_mday; y.h = pTm->tm_hour; y.m = pTm->tm_min; y.s = pTm->tm_sec; sqlite3OsLeaveMutex(); Windows and some versions of UNIX may use thread-local storage to make localtime() threadsafe. This is not the case with Linux or any other OS that uses GNU libc: /* Convert `time_t' to `struct tm' in local time zone. Copyright (C) 1991,92,93,95,96,97,98,2002 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ #include /* The C Standard says that localtime and gmtime return the same pointer. */ struct tm _tmbuf; /* Return the `struct tm' representation of *T in local time, using *TP to store the result. */ struct tm * __localtime_r (t, tp) const time_t *t; struct tm *tp; { return __tz_convert (t, 1, tp); } weak_alias (__localtime_r, localtime_r) /* Return the `struct tm' representation of *T in local time. */ struct tm * localtime (t) const time_t *t; { return __tz_convert (t, 1, &_tmbuf); } libc_hidden_def (localtime) As an added benefit, you get better thread concurrency by getting rid of the sqlite3OsEnterMutex/sqlite3OsLeaveMutex when you use localtime_r. _2006-May-15 12:53:42 by drh:_ {linebreak} All of this is pointed out already in the documentation. I will therefore change this ticket from a bug to an enhancement request. Note that we have considered the use of localtime_r() in the past and rejected it since it will lead to a significant complication of the build process.
#f2dcdc 1790 code active 2006 May anonymous Pager 2006 May 3 3 :memory: performance difference between v2 and v3 Please see the following link for details: http://www.mail-archive.com/sqlite-users%40sqlite.org/msg14937.html Possible fix? RCS file: /sqlite/sqlite/src/pager.c,v retrieving revision 1.266 diff -u -r1.266 pager.c --- pager.c 7 Apr 2006 13:54:47 -0000 1.266 +++ pager.c 3 May 2006 19:02:17 -0000 @@ -1663,7 +1663,7 @@ pPager->memDb = memDb; pPager->readOnly = readOnly; /* pPager->needSync = 0; */ - pPager->noSync = pPager->tempFile || !useJournal; + pPager->noSync = pPager->tempFile || !pPager->useJournal; pPager->fullSync = (pPager->noSync?0:1); /* pPager->pFirst = 0; */ /* pPager->pFirstSynced = 0; */ _2006-May-03 19:32:12 by drh:_ {linebreak} The suggested change makes no difference in performance when I try it. ---- _2006-May-03 21:41:24 by anonymous:_ {linebreak} If transactions are not used, 85% of the time of this memory database benchmark is spent in pager_get_all_dirty_pages(). Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 85.25 31.20 31.20 100002 0.31 0.31 pager_get_all_dirty_pages 1.39 31.71 0.51 100011 0.01 0.20 sqlite3VdbeExec 1.17 32.14 0.43 10487713 0.00 0.00 parseCellPtr 0.63 32.37 0.23 12943618 0.00 0.00 sqlite3VdbeSerialGet 0.61 32.59 0.23 3432951 0.00 0.00 pager_lookup 0.52 32.78 0.19 4849544 0.00 0.00 sqlite3VdbeRecordCompare 0.44 32.95 0.16 400006 0.00 0.00 sqlite3BtreeMoveto 0.41 33.09 0.15 2064924 0.00 0.00 sqlite3pager_get 0.40 33.24 0.14 6471807 0.00 0.00 sqlite3MemCompare 0.06 31.25 100002/100002 sqlite3BtreeCommit [4] [5] 85.6 0.06 31.25 100002 sqlite3pager_commit [5] 31.20 0.00 100002/100002 pager_get_all_dirty_pages [6] 0.05 0.00 389365/389365 clearHistory [65] ----------------------------------------------- 31.20 0.00 100002/100002 sqlite3pager_commit [5] [6] 85.2 31.20 0.00 100002 pager_get_all_dirty_pages [6] ---- _2006-May-03 21:51:30 by anonymous:_ {linebreak} Stats with BEGIN/COMMIT enabled: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 11.88 0.34 0.34 4849544 0.00 0.00 sqlite3VdbeRecordCompare 8.16 0.56 0.23 10487713 0.00 0.00 parseCellPtr 7.80 0.79 0.22 12943618 0.00 0.00 sqlite3VdbeSerialGet 6.38 0.96 0.18 100013 0.00 0.03 sqlite3VdbeExec 4.26 1.08 0.12 29816 0.00 0.02 balance_nonroot 3.90 1.20 0.11 6471807 0.00 0.00 sqlite3MemCompare 3.19 1.28 0.09 1964925 0.00 0.00 sqlite3pager_get 3.19 1.38 0.09 400006 0.00 0.00 sqlite3BtreeMoveto 2.84 1.46 0.08 19170231 0.00 0.00 get2byte 2.66 1.53 0.07 700015 0.00 0.00 sqlite3VdbeSerialPut 2.13 1.59 0.06 600993 0.00 0.00 sqlite3Malloc 1.77 1.64 0.05 4400155 0.00 0.00 sqlite3pager_unref 1.77 1.69 0.05 3332952 0.00 0.00 pager_lookup 1.77 1.74 0.05 1418379 0.00 0.00 decodeFlags 1.77 1.79 0.05 1332302 0.00 0.00 initPage 1.60 1.83 0.04 5270826 0.00 0.00 findOverflowCell 1.42 1.88 0.04 12181181 0.00 0.00 findCell 1.42 1.92 0.04 4849549 0.00 0.00 fetchPayload 1.42 1.96 0.04 359548 0.00 0.00 insertCell 1.24 1.99 0.04 4896877 0.00 0.00 parseCell 1.06 2.02 0.03 5284245 0.00 0.00 cellSizePtr 1.06 2.05 0.03 3227291 0.00 0.00 binCollFunc 1.06 2.08 0.03 2616113 0.00 0.00 _page_ref 1.06 2.11 0.03 1368027 0.00 0.00 reparentPage 1.06 2.14 0.03 934205 0.00 0.00 sqlite3GenericMalloc 1.06 2.17 0.03 300010 0.00 0.00 sqlite3BtreeCursor 0.89 2.19 0.03 2536689 0.00 0.00 get4byte 0.89 2.22 0.03 1864920 0.00 0.00 getPage ... 0.00 2.82 0.00 3 0.00 0.00 pager_get_all_dirty_pages 0.00 0.00 3/3 sqlite3BtreeCommit [116] [119] 0.0 0.00 0.00 3 sqlite3pager_commit [119] 0.00 0.00 6551/6551 clearHistory [118] 0.00 0.00 3/3 pager_get_all_dirty_pages [370] ----------------------------------------------- 0.00 0.00 3/3 sqlite3pager_commit [119] [370] 0.0 0.00 0.00 3 pager_get_all_dirty_pages [370] ---- _2006-May-03 22:27:35 by anonymous:_ {linebreak} with the outer BEGIN/COMMIT disabled, the memory database benchmark stats: static PgHdr *pager_get_all_dirty_pages(Pager *pPager){ // this point is reached 100,002 times PgHdr *p, *pList; pList = 0; for(p=pPager->pAll; p; p=p->pNextAll){ // this point is reached 322,956,271 times if( p->dirty ){ // this point is reached 389,365 times p->pDirty = pList; pList = p; } } return pList; } ---- _2006-May-04 05:23:08 by anonymous:_ {linebreak} This patch makes the test (with transaction) run 7% faster for gcc 3.4.4 with -O2. At -O3, gcc performs the inlining of these functions even without the inline hint, so this patch has no effect. RCS file: /sqlite/sqlite/src/btree.c,v retrieving revision 1.324 diff -u -3 -p -r1.324 btree.c --- btree.c 4 Apr 2006 01:54:55 -0000 1.324 +++ btree.c 4 May 2006 05:12:35 -0000 @@ -439,17 +439,17 @@ static int checkReadLocks(BtShared*,Pgno /* ** Read or write a two- and four-byte big-endian integer values. */ -static u32 get2byte(unsigned char *p){ +inline static u32 get2byte(unsigned char *p){ return (p[0]<<8) | p[1]; } -static u32 get4byte(unsigned char *p){ +inline static u32 get4byte(unsigned char *p){ return (p[0]<<24) | (p[1]<<16) | (p[2]<<8) | p[3]; } -static void put2byte(unsigned char *p, u32 v){ +inline static void put2byte(unsigned char *p, u32 v){ p[0] = v>>8; p[1] = v; } -static void put4byte(unsigned char *p, u32 v){ +inline static void put4byte(unsigned char *p, u32 v){ p[0] = v>>24; p[1] = v>>16; p[2] = v>>8; ---- _2006-May-04 19:44:57 by anonymous:_ {linebreak} I just want to confirm that a _file database is faster_ than a memory database for 3.3.5+. Are these numbers correct? 43,478 inserts/second best case for file for 3.3.5+ and 40,000 inserts/second best case for memory? Even with the OS caching the entire database file entirely in RAM, this finding is quite surprising. Test DB IDX TX RC 3.3.5+ 3.3.5 2.8.17 1 mem n y 1000000 40000 33333 76923 2 mem y y 1000000 27027 22727 58824 3 mem n n 1000000 35714 5263 83333 4 mem y n 1000000 24390 2778 62500 5 file n y 1000000 43478 35714 40000 6 file y y 1000000 28571 24390 23256 7 file n n 1000 11 11 13 8 file y n 1000 9 10 13 http://www.sqlite.org/cvstrac/attach_get/256/sqlite_speed.txt ---- _2006-May-04 20:19:18 by anonymous:_ {linebreak} I'm seeing slightly different results. The memory database using a transaction is (slightly) faster than the file-based database using a transaction. Timings on 3.3.5+ on Windows XP, gcc 3.4.4 -O3 -fomit-frame-pointer IDX TX # inserts wall time inserts/sec --- --- --------- ---------- ----------- mem no no 100,000 4.8s 20,833 mem no yes 100,000 4.3s 23,255 file no yes 100,000 4.7s 21,276 file no no 1,000 99.8s 10 ...things get worse for :memory: as you increase the number of inserts, while the file database numbers remain constant: IDX TX # inserts wall time inserts/sec --- --- --------- ---------- ----------- mem no yes 1,000,000 48.5s 20,638 mem no yes 2,000,000 118.6s 16,863 mem no yes 4,000,000 364.7s 10,967 file no yes 1,000,000 46.8s 21,354 file no yes 2,000,000 93.8s 21,321 file no yes 4,000,000 187.5s 21,333 Do Linux users get similar results? Considering I have 512K CPU L2 cache, I wonder if there's some CPU cache effect going on here with the way the :memory: db is allocated. ---- _2006-May-04 21:35:07 by anonymous:_ {linebreak} It seems there is some quadratic behavior in pager_lookup (latest CVS). 52% of the time is spent in that function. Profile data from :memory: db, TX on, no IDX, 4 million inserts: /* ** Find a page in the hash table given its page number. Return ** a pointer to the page or NULL if not found. */ static PgHdr *pager_lookup(Pager *pPager, Pgno pgno){ PgHdr *p = pPager->aHash[pager_hash(pgno)]; while( p && p->pgno!=pgno ){ p = p->pNextHash; } return p; } % cumulative self self total time seconds seconds calls ms/call ms/call name 51.97 118.31 118.31 119658386 0.00 0.00 pager_lookup 4.36 128.25 9.94 4000009 0.00 0.06 sqlite3VdbeExec 3.06 135.21 6.96 315629923 0.00 0.00 parseCellPtr 3.05 142.16 6.95 171797186 0.00 0.00 sqlite3VdbeRecordCompare 2.67 148.22 6.07 12000005 0.00 0.01 sqlite3BtreeMoveto 2.14 153.10 4.88 343594380 0.00 0.00 sqlite3VdbeSerialGet 1.68 156.93 3.83 171797188 0.00 0.00 sqlite3MemCompare 1.63 160.65 3.72 77995781 0.00 0.00 sqlite3pager_get 1.60 164.29 3.65 169734946 0.00 0.00 sqlite3pager_unref 1.58 167.88 3.59 654100795 0.00 0.00 get2byte 1.30 170.84 2.95 973877 0.00 0.07 balance_nonroot 1.27 173.74 2.90 56939555 0.00 0.00 initPage 1.24 176.56 2.83 171797188 0.00 0.00 binCollFunc 0.93 178.69 2.12 386371475 0.00 0.00 findCell 0.86 180.65 1.96 96207437 0.00 0.00 pageDestructor 0.83 182.53 1.89 95976540 0.00 0.00 _page_ref 0.80 184.36 1.83 2708031 0.00 0.00 assemblePage 0.80 186.19 1.82 41662605 0.00 0.00 reparentPage 0.74 187.88 1.70 171797188 0.00 0.00 fetchPayload 0.73 189.55 1.67 73995778 0.00 0.00 getPage 0.67 191.07 1.52 59647596 0.00 0.00 decodeFlags 0.63 192.51 1.44 132945443 0.00 0.00 findOverflowCell 0.62 193.93 1.41 40148167 0.00 0.00 sqlite3PutVarint 0.59 195.27 1.34 134687272 0.00 0.00 releasePage 0.59 196.62 1.34 73764879 0.00 0.00 getAndInitPage 0.54 197.84 1.22 8000003 0.00 0.02 sqlite3BtreeInsert 0.52 199.01 1.18 60000030 0.00 0.00 sqlite3VdbeSerialType 0.52 200.19 1.18 24000011 0.00 0.00 moveToRoot 0.49 201.30 1.10 179797130 0.00 0.00 getCellInfo 0.43 202.28 0.98 9882306 0.00 0.00 insertCell 0.42 203.22 0.94 47288132 0.00 0.00 moveToChild 0.40 204.15 0.92 173434760 0.00 0.00 parseCell 0.40 205.06 0.91 95806930 0.00 0.00 get4byte 0.34 205.83 0.78 41662605 0.00 0.00 sqlite3pager_lookup 0.33 206.57 0.74 165099370 0.00 0.00 sqlite3MallocFailed 0.32 207.31 0.73 20000010 0.00 0.00 sqlite3VdbeSerialPut 0.31 208.02 0.71 8000015 0.00 0.00 sqlite3VdbeHalt 0.30 208.70 0.68 27052986 0.00 0.00 sqlite3GetVarint 0.28 209.33 0.63 174637767 0.00 0.00 put2byte 0.27 209.96 0.62 8000006 0.00 0.00 sqlite3BtreeCursor 0.26 210.54 0.59 8148152 0.00 0.00 fillInCell 0.25 211.12 0.57 3385610 0.00 0.01 reparentChildPages 0.25 211.69 0.57 16000006 0.00 0.00 checkReadLocks 0.22 212.19 0.51 48000093 0.00 0.00 sqlite3VdbeFreeCursor 0.22 212.69 0.50 133898861 0.00 0.00 cellSizePtr 0.22 213.19 0.50 24000010 0.00 0.00 popStack 0.20 213.65 0.46 50076560 0.00 0.00 sqlite3pager_ref 0.20 214.10 0.45 pager_reset 0.19 214.54 0.44 8000024 0.00 0.00 closeAllCursors 0.19 214.97 0.42 12000024 0.00 0.00 sqlite3VdbeMemMakeWriteable 0.18 215.38 0.41 32000052 0.00 0.00 sqlite3VdbeMemSetStr 0.18 215.78 0.40 11616158 0.00 0.00 allocateSpace 0.17 216.16 0.39 8000000 0.00 0.00 bindText 0.16 216.51 0.35 25098767 0.00 0.00 sqlite3MallocRaw 0.16 216.87 0.35 8000005 0.00 0.00 sqlite3BtreeCloseCursor 0.15 217.22 0.34 45560699 0.00 0.00 sqlite3FreeX 0.15 217.56 0.34 36000014 0.00 0.00 sqlite3VarintLen 0.15 217.90 0.34 36000009 0.00 0.00 sqlite3VdbeMemShallowCopy 0.14 218.22 0.33 47999969 0.00 0.00 sqlite3VdbeSerialTypeLen 0.14 218.54 0.33 4000008 0.00 0.00 sqlite3VdbeMakeReady ----------------------------------------------- 41.19 0.00 41662605/119658386 sqlite3pager_lookup [15] 77.12 0.00 77995781/119658386 sqlite3pager_get [8] [5] 52.0 118.31 0.00 119658386 pager_lookup [5] ----------------------------------------------- 0.19 4.02 4000003/77995781 sqlite3BtreeGetMeta [28] 3.53 74.30 73995778/77995781 getPage [9] [8] 36.0 3.72 78.31 77995781 sqlite3pager_get [8] 77.12 0.00 77995781/119658386 pager_lookup [5] 1.12 0.00 56939550/95976540 _page_ref [40] 0.03 0.00 230897/230897 page_remove_from_stmt_list [139] 0.03 0.00 230897/230897 makeClean [138] 0.01 0.00 230897/461804 sqlite3pager_pagecount [150] 0.00 0.00 230897/25098767 sqlite3MallocRaw [58] ----------------------------------------------- 1.82 44.94 41662605/41662605 reparentChildPages [13] [14] 20.5 1.82 44.94 41662605 reparentPage [14] 0.78 41.96 41662605/41662605 sqlite3pager_lookup [15] 2.21 0.00 41672966/131189801 sqlite3pager_unref [31] 0.00 0.00 93099/50076560 sqlite3pager_ref [75] ----------------------------------------------- 0.78 41.96 41662605/41662605 reparentPage [14] [15] 18.8 0.78 41.96 41662605 sqlite3pager_lookup [15] 41.19 0.00 41662605/119658386 pager_lookup [5] 0.77 0.00 39036990/95976540 _page_ref [40] ----------------------------------------------- 0.77 0.00 39036990/95976540 sqlite3pager_lookup [15] 1.12 0.00 56939550/95976540 sqlite3pager_get [8] [40] 0.8 1.89 0.00 95976540 _page_ref [40] ---- _2006-May-04 21:41:37 by anonymous:_ {linebreak} I guess increasing this array size is in order: PgHdr *aHash[N_PG_HASH]; /* Hash table to map page number to PgHdr */ Too many hash collisions leading to growing linked lists in buckets. Or perhaps pager_hash has to be replaced with a better hash function. ---- _2006-May-04 22:04:47 by anonymous:_ {linebreak} Increasing the size of N_PG_HASH to 8192 seems to help the "4 million insert in a transaction into a memory database" benchmark. It now runs in 203.5 seconds (19656 inserts/sec), as opposed to 364.7 seconds (10967 inserts/sec) previously. This is closer to the 187.5 seconds for the file-based database timing. ---- _2006-May-04 22:13:16 by anonymous:_ {linebreak} Increasing N_PG_HASH to 16384 yields 21,052 inserts/second for a 4 million insert single-transaction :memory: database no-index run. This is very close to the file database figure of 21,333 inserts/second. ---- _2006-May-04 22:23:19 by anonymous:_ {linebreak} Setting N_PG_HASH to 32768 yields 21,621 inserts/second in the 4M insert s in a single-transaction in a memory db test. This is marginally faster than the file based database timing. Increasing N_PG_HASH has diminishing returns after 16384. ---- _2006-May-05 15:33:31 by anonymous:_ {linebreak} You should get the same effect if you increase the page size instead of increasing the size of the hash table. With a larger page size there will be fewer pages to be managed by the hash table. This might be a better solution for many applications. A hash table with 32K entries occupies 128K of RAM, whether it is used or not. ---- _2006-May-05 19:37:51 by anonymous:_ {linebreak} 128K of RAM when dealing with a 230M :memory: database is not terribly significant. Here's the timings for various N_PG_HASH and SQLITE_DEFAULT_PAGE_SIZE values for 4 million inserts into a :memory: database in a single transaction: N_PG_HASH SQLITE_DEFAULT_PAGE_SIZE inserts/sec --------- ------------------------ ----------- 16384 4096 21,622 32768 1024 21,621 8192 8192 20,513 4096 4096 20,101 4096 8192 19,417 2048 4096 16,878 2048 8192 16,598 2048 16384 15,038 2048 32768 13,937 2048 1024 10,782 So it seems the default values of N_PG_HASH and SQLITE_DEFAULT_PAGE_SIZE should be raised. ---- _2006-May-05 21:34:01 by anonymous:_ {linebreak} My point was that most users do not have 230 MB memory databases, so having a large hash table which is fixed at that size may be a burden. 128K for the hash table is a lot if you only have 128K in your memmory database. I agree that increasing these values would seem to provide a substantial performance increase at little cost. I would suggest using the 4K hash table and the 4K page size. These values are close to the current values. Many users have reported a general speed improvement using a page size of 4K which matches the value used by WinXP (and think many other Os's as well) for disk I/O blocks. These values nearly double the insert rate over the current default values. The fixed size hash table only takes twice the space. ---- _2006-May-06 14:54:32 by anonymous:_ {linebreak} Memory page speed should be as fast as possible as it effects the general performance of SQLite. Perhaps a static hash table is not the best data structure here. Don't temp tables and intermediate select results on file-based tables use memory-based pages? Making memory page speed as fast as possible will improve overall SQLite performance whether you are using a file or memory based database. For example, when ordering result sets from a file-based database select this routine is used to generate the code: static void pushOntoSorter( Parse *pParse, /* Parser context */ ExprList *pOrderBy, /* The ORDER BY clause */ Select *pSelect /* The whole SELECT statement */ ){ Vdbe *v = pParse->pVdbe; sqlite3ExprCodeExprList(pParse, pOrderBy); sqlite3VdbeAddOp(v, OP_Sequence, pOrderBy->iECursor, 0); sqlite3VdbeAddOp(v, OP_Pull, pOrderBy->nExpr + 1, 0); sqlite3VdbeAddOp(v, OP_MakeRecord, pOrderBy->nExpr + 2, 0); sqlite3VdbeAddOp(v, OP_IdxInsert, pOrderBy->iECursor, 0); For those of us who have very complicated nested sub-selects of file-based tables in many queries or even ORDER BYs on huge result sets, speeding up the memory page performance should be a performance win for SQLite in general. ---- _2006-May-06 17:37:32 by anonymous:_ {linebreak} The following test demonstrates that this memory page issue can greatly effect the performance of queries against file-based tables if temp_store is set to MEMORY. "big" is a file-based table in foo.db with 10 million rows. It was created with "create table big(x,y)". # unmodified stock SQLite built from May 5 2006 CVS (after check-in [3178]) # compiled with default settings for SQLITE_DEFAULT_PAGE_SIZE and N_PG_HASH $ time ./may5-sqlite/sqlite3 foo.db "PRAGMA temp_store = MEMORY; select x, y from big order by y, x" >/dev/null real 13m23.828s user 13m18.452s sys 0m0.811s # SQLite built from May 5 2006 CVS, but compiled with proposed change of # SQLITE_DEFAULT_PAGE_SIZE set to 4096, and N_PG_HASH set to 16384 $ time ./may5-sqlite-hash-opt/sqlite3 foo.db "PRAGMA temp_store = MEMORY; select x, y from big order by y, x" >/dev/null real 6m16.031s user 6m13.108s sys 0m0.811s This is not even what I would consider to be a big table. I should mention that compiling with SQLITE_DEFAULT_PAGE_SIZE = 1024, and N_PG_HASH = 32768 resulted in same timing as the may5-sqlite-hash-opt test run above. A pretty good return for an extra 126K. ---- _2006-May-08 04:07:25 by anonymous:_ {linebreak} You now get 20,725 inserts/second as of the latest check-in [3180] for 4 million inserts into a :memory: database in a single transaction (using the default SQLITE_DEFAULT_PAGE_SIZE of 1K). This is nearly twice as fast as SQLite prior to the check-in [3180] (10,782 inserts/second). However, it is 4% slower than the best timing prior to [3180] when compiled with N_PG_HASH=32768 and SQLITE_DEFAULT_PAGE_SIZE=1024 which got 21,622 inserts/second (see table above). Increasing the size of SQLITE_DEFAULT_PAGE_SIZE with the latest CVS either has no effect or makes the memory insert benchmark timings slightly worse.
#f2dcdc 1783 code active 2006 Apr anonymous Unknown 2006 Apr 3 2 insert times increase with growing table size (when indexed) The time needed to insert (or update) entries in a table with an index on one of the fields increases with the size of the table. For large databases inserts become very slow (which I suppose is likely the problem in ticket #1547). sqlite2 does not have this scaling problem on inserts. (Some of our queries do not scale on sqlite2 however, making its use also impossible.) ----- example code ----- package require dbi package require dbi_sqlite3 dbi_sqlite3 db db create /tmp/test.db db open /tmp/test.db db exec {create table "region" ( "id" integer not null primary key, "start" integer, "end" integer )} db exec {create index "region_index" on "region"("start")} set num 1 for {set j 1} {$j < 20} {incr j} { puts [lindex [time { db begin for {set i 1} {$i < 100000} {incr i} { set s [expr {round(rand()*1000000)}] set e [expr {round(rand()*1000000)}] db exec { insert into "region"("id","start","end") values(?,?,?) } $num $s $e incr num } db commit }] 0] } ----- timings ----- 5712186 6621934 9492997 13234978 14881322 19119044 25296162 26670866 35378986 35877042 44383517 54576510 53317621 63516664 76587973 73791188 88460462 101650099
#f2dcdc 1633 code active 2006 Jan anonymous VDBE 2006 Apr 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) ?
#e8e8bd 1781 new active 2006 Apr anonymous 2006 Apr 3 5 Interleaved sqlite_step behaves inconsistently I am not sure if 'interleaved' is the correct term to use, but I will explain what I am doing. I have listed this ticket type as "code defect", maybe "documentation" or "incident" would have been just as good. The issue here is that the sqlite3_step may fail or succeed depending on an 'irrelevant' ORDER BY clause - atleast irrelevant to my results. I have a loop that performs a query using sqlite3_step(q), inside the loop the data from the resuling row is used to update a table using sqlite3_step(u). I know that I do not have to do it this way, I could cache the query results in an array thus avoiding the interleaving, but I am not doing that here for the purpose of illustrating this issue. If what I am doing is illegal, it should not return success by just adding an ORDER BY clause, I think it should fail and be documented as such. When it succeeds, the results are 100% perfect everytime, so I know SQLite can do this. If what I am doing is legal, why does it fail without the ORDER BY clause. Contrived code that would reproduce the issue: sqlite3* db; sqlite3_stmt* stmtquery; sqlite3_stmt* stmtupdate; const char queryok[] = "SELECT c1, c2 FROM t1 WHERE c2='row' ORDER BY c1;"; // ** ORDER BY c1 const char query[] = "SELECT c1, c2 FROM t1 WHERE c2='row';"; const char update[] = "UPDATE t1 SET c2='foo' WHERE c1=1;"; int ret = sqlite3_open( ":memory:", &db ); ret = sqlite3_exec( db, "create table t1 (c1, c2);", NULL, NULL, NULL ); ret = sqlite3_exec( db, "insert into t1 (c2) values ('row');", NULL, NULL, NULL ); ret = sqlite3_exec( db, "insert into t1 (c2) values ('row');", NULL, NULL, NULL ); // success using queryok (ORDER BY) ret = sqlite3_prepare( db, queryok, -1, &stmtquery, NULL ); // SQLITE_OK ret = sqlite3_step( stmtquery ); // SQLITE_ROW ret = sqlite3_prepare( db, update, -1, &stmtupdate, NULL ); // SQLITE_OK ret = sqlite3_step( stmtupdate ); // SQLITE_DONE ret = sqlite3_finalize( stmtquery ); // SQLITE_OK ret = sqlite3_finalize( stmtupdate ); // SQLITE_OK // same code fails using query (no ORDER BY) ret = sqlite3_prepare( db, query, -1, &stmtquery, NULL ); // SQLITE_OK ret = sqlite3_step( stmtquery ); // SQLITE_ROW ret = sqlite3_prepare( db, update, -1, &stmtupdate, NULL ); // SQLITE_OK ret = sqlite3_step( stmtupdate ); // ** SQLITE_ERROR ret = sqlite3_finalize( stmtquery ); // SQLITE_OK ret = sqlite3_finalize( stmtupdate ); // ** SQLITE_LOCKED // is this the only supported way? ret = sqlite3_prepare( db, query, -1, &stmtquery, NULL ); // SQLITE_OK ret = sqlite3_step( stmtquery ); // SQLITE_ROW ret = sqlite3_finalize( stmtquery ); // SQLITE_OK ret = sqlite3_prepare( db, update, -1, &stmtupdate, NULL ); // SQLITE_OK ret = sqlite3_step( stmtupdate ); // SQLITE_DONE ret = sqlite3_finalize( stmtquery ); // SQLITE_OK ret = sqlite3_close( db ); _2006-Apr-24 14:52:51 by anonymous:_ {linebreak} While the order by clause may be superfluous to you, it isn't to sqlite. To implement order by, sqlite must have an index on the column used for ordering, in which case it can scan the table in the expected order, or it must scan the table entire table copying records to a temporary table which it then sorts into the required order. In the first case the table is still being read while it is being scanned, so it is open when the first result is retuned. In the second case, the table is read during the table scan, then closed. Only the temporary table is open for reading when the first result is returned. A query without an order by clause always scans the table in the same manner as the first case. I.e. the table is open for reading when the first result is returned. Sqlite does not allow a table to be updated while it is open for reading, hence you will get an error in the first case, or with a query that does not have an order by clause. The fact that it works with the order by clause in your case is a side effect of the fact that sqlite had to create a temporary table to sort the results. The main table is closed, and it is returning results from the temporary table when you try to do the update. This would break if you were to add an index on the column that you are ordering by.
#e8e8bd 1762 build active 2006 Apr anonymous Unknown 2006 Apr 3 4 sqlite3_clear_bindings not exported in windows dll While documented sqlite3_clear_bindings is not exported in the def file for the windows dll. Therefore it is unable to link.
#f2dcdc 1743 code active 2006 Mar anonymous Parser 2006 Mar 3 3 A very very deep IN statement failure Ok the problem is simple. I need to create a VERY VERY large IN statement. The problem is SQLite seems to have a limit on either query length or depth of an IN statement. Here is my example See attached 1 That would be a 2 levels deep In statement. I can only get up to 9 with SQLite but I need to get to 20. Since it works for 9 I can only assume that my 10 is correct even though the error is a syntax error. Below is the code that creates the select statement. See attached 4 Attachment 2 and 3 show a 9 and 10 level respectively. Thanks for your help _2006-Mar-30 21:30:51 by anonymous:_ Select "Wow !!" from "Wow !!" :-) Maybe VIEWs could help ?? ---- _2006-Mar-30 21:37:50 by anonymous:_ {linebreak} This may be a work around for your problem. From looking at your sample SQL: SELECT * FROM xs where classname like '%Bonus_Pay_Weight_Entry%' or classname in ( select parentname from xs where classname in ( select parentname from xs where classname in ( select parentname from xs where classname like '%Bonus_Pay_Weight_Entry%' ) ) ) or classname in ( select parentname from xs where classname in ( select parentname from xs where classname like '%Bonus_Pay_Weight_Entry%' ) ) or classname in ( select parentname from xs where classname like '%Bonus_Pay_Weight_Entry%' ) ; It seems you are trying to find all the parent classes of all the classes with this magic string in their name. If so, I think there is another way to do this. Instead of using a C program to build a huge SQL statement and then collect the results, use a different C program to execute a series of small SQL commands that generate the same result set. The following series of SQL statements should generate the same set of results. create temp table xt as select classname from xs where classname like '%Bonus_Pay_Weight_Entry%'; insert into xt select parentname from xs where classname in xt and parentname not in xt; select changes(); insert into xt select parentname from xs where classname in xt and parentname not in xt; select changes(); insert into xt select parentname from xs where classname in xt and parentname not in xt; select changes(); ... repeat until changes returns zero select * from xs where classname in xt; drop table xt; This can be execute by code that looks something like the following pseudo-C code. string sql; sql = "create temp table xt as select classname from xs where classname like '%Bonus_Pay_Weight_Entry%'"; sqlite3_exec(db, sql); sql = "insert into xt select parentname from xs where classname in xt and parentname not in xt"; sqlite3_stmt* extend = sqlite3_prepare(db, sql); sql = "select changes()" sqlite3_stmt* check = sqlite3_prepare(db, sql); int changes = 0; do { sqlite3_step(extend); sqlite3_reset(extend); sqlite3_step(check); changes = sqlite3_column_int(check, 0); sqlite3_reset(check); } while (changes > 0); sqlite3_finalize(extend); sqlite3_finalize(check); sql = "select * from xs where classname in xt"; sqlite3_stmt* get = sqlite3_prepare(db, sql); int rc; do { rc = sqlite3_step(get); if (rc == SQLITE_DONE) break; // process a result row } while (1); sqlite3_finalize(get); sql = "drop table xt"; sqlite3_exec(db, sql); ---- _2006-Apr-05 17:25:30 by anonymous:_ {linebreak} Where did you find the select changes(); function? I would like to find all the functions that SQLite has and their uses. (and no I dont want the C API. I found that) ---- _2006-Apr-05 18:53:08 by anonymous:_ {linebreak} There is no complete listing of the functions in the documentation that I am aware of. Most are documented on this page http://www.sqlite.org/lang_expr.html but some are missing. The ultimate list of the predefined functions is the source file func.c which implements all the functions. You can view it here http://www.sqlite.org/cvstrac/rlog?f=sqlite/src/func.c
#e8e8bd 1720 new active 2006 Mar anonymous 2006 Mar 3 4 Actions made by a trigger are not triggered Hellow, CREATE TRIGGER trg_del_event BEFORE DELETE ON event FOR EACH ROW BEGIN SELECT RAISE(ROLLBACK, 'Cannot delete : event is referenced in table active_stuff') WHERE (SELECT id FROM active_stuff WHERE event_id = OLD.id) IS NOT NULL; DELETE from event WHERE parent_event_id = OLD.id; END; This trigger verify if the current event is referenced in active_stuff table and if not, delete the row and the childs of the event. The problem is that the delete made by this trigger is not triggered itself : There's no verification on event's child and no global rollback. I don't know exactly if it's a feature or an incident. If it's a feature, you can simply close this ticket. Thanks :) _2006-Mar-19 17:38:15 by anonymous:_ {linebreak} I believe it was mentioned on the mailing list that SQLite triggers are not recursive. However, I don't see any mention of this in the documentation: http://www.sqlite.org/lang_createtrigger.html ---- _2006-Mar-19 17:49:57 by anonymous:_ {linebreak} Yes, it's right, I've just found this in ML : Re: [sqlite] Are DELETE TRIGGERS recursive or not? drh Tue, 25 Oct 2005 06:38:42 -0700 Ralf Junker <[EMAIL PROTECTED]> wrote: > I wonder if a DELETE TRIGGER should trigger itself recursively Not at this time. Though work is underway to change this. We need recusive delete triggers in order to implement cascadinig deletes for referential integrity. -- D. Richard Hipp <[EMAIL PROTECTED]> So it's not a bug :) It's : - a documentation problem (missing "triggers are currently no recursive") - a feature request :) ---- _2006-Mar-19 19:42:58 by anonymous:_ {linebreak} Finally I've found the limitation here : http://www.sqlite.org/omitted.html
#e8e8bd 1701 doc active 2006 Mar anonymous 2006 Mar drh 3 1 3.3 build option not documented? 3.3 db can not be read in easlier 3.X versions. Ok, then it says there is a 'rare' compile option to force them to be. I can not use 3.3 yet from php and perl, so I have the rare condidtion that I prefer to have all my tools in sync more. I have searched the incompatibilies page, the ./configure -h, grepped the source and read the options page... so far none seem to have lead me to this magic compile option. Maybe it should be documented someplace? _2006-Mar-03 15:49:35 by anonymous:_ {linebreak} The compilation option you are looking for is SQLITE_DEFAULT_FILE_FORMAT. I found it by looking back through the time line before version 3.3.0. You are correct it should be added to the options displayed on http://www.sqlite.org/compile.html which is reached from the Compilation Options link on the documentation page.
#e8e8bd 1647 doc active 2006 Jan anonymous Unknown 2006 Jan paul 3 1 i want to use this lib in my project HI, I want to use this sqlite source in my project for quick firing of quaries. I want dataled doc of source or how to use these source in my project. Hoping for quick reply, Bye thaks & Regards Sumant Kadam 9422615104 _2006-Jan-30 20:43:26 by anonymous:_ {linebreak} This is not a bug report. Please use the mailing list for this type of question.
#e8e8bd 867 new active 2004 Aug anonymous Parser 2006 Jan 3 2 update on multiple tables I would like to have update working on multi tables; It is not written as possible thus it is a request for enhancement. basic example: create table a ( id integer primary key, val integer ); create table b ( id integer primary key, val integer ); insert into a (val) values (314); insert into a (val) values (315); insert into b (val) values (314); insert into b (val) values (314); update a, b set b.val = a.val; _2006-Jan-24 19:01:31 by anonymous:_ {linebreak} I would prefer another syntax - using a SELECT as the source for data to be updated. UPDATE SET =... WHERE = ... SELECT FROM WHERE =... This is the update syntax used in PostgreSQL and other databases. I also believe this is easier to understand and easier to implement (since the select is just the source for data) ---- _2006-Jan-24 19:21:15 by anonymous:_ {linebreak} Already supported via correlated subquery: update b set val = (select a.val from a where a.id = b.id); See: http://www.sqlite.org/lang_update.html
#e8e8bd 1638 warn active 2006 Jan anonymous 2006 Jan 3 2 rows place change and some row element missing there is a problem with my table row order.I miss one roe header and the next one come to its place.also there is a problem like this in the columns too.it does not occur when the table is list or line.but when I turn it into column mode the problem happens.my table become puzzling
#e8e8bd 1591 build active 2006 Jan anonymous 2006 Jan 3 2 Missing TEXE suffix in linking and install rules for sqlite3 Suffix $(TEXE) is missing at some places in Makefile.in. It makes dependencies and rules inconsistant, when TEXE is not null (e.g. .exe when compiling with MingW for MSWin target). Those rules has to be fixed: *: When linking slqite3 executable: use -o sqlite3$(TEXE) instead of -o sqlite3 in linker command line to use (especially since $(TEXE) suffix is present in rule) *: When installing: use{linebreak} $(LTINSTALL) sqlite3$(TEXE) $(DESTDIR)$(exec_prefix)/bin{linebreak} instead of{linebreak} $(LTINSTALL) sqlite3 $(DESTDIR)$(exec_prefix)/bin{linebreak} Similar fixes need to be applied to tclsqlite3 (missing in both rule and linker command line), testfixture (in linker cmdline), crashtest (in linker cmdline), lemon (in linker cmdline, with $(BEXE) suffix).
#e8e8bd 1577 build active 2005 Dec anonymous Unknown 2005 Dec drh 3 3 32bit compile on 64bit system fails to build sqlite3 On a linux amd64 x86_64 system (dual core cpu, smp kernel) Recieve a ./libtool --mode=link gcc -m32 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I../sqlite-3.2.8/src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=1 -I/usr/include/readline -lpthread \ -o sqlite3 ../sqlite-3.2.8/src/shell.c libsqlite3.la -lncurses gcc -m32 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I../sqlite-3.2.8/src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_OMIT_CURSOR -DHAVE_READLINE=1 -I/usr/include/readline -o .libs/sqlite3 ../sqlite-3.2.8/src/shell.c ./.libs/libsqlite3.so -lpthread -lncurses /tmp/ccQ7Hvlw.o: In function `one_input_line': shell.c:(.text+0x35b): undefined reference to `readline' shell.c:(.text+0x36f): undefined reference to `add_history' /tmp/ccQ7Hvlw.o: In function `main': shell.c:(.text+0x4a38): undefined reference to `read_history' shell.c:(.text+0x4a63): undefined reference to `stifle_history' shell.c:(.text+0x4a71): undefined reference to `write_history' --- Note that the CFLAGS=-m32 and CPPFLAGS=-m32 and LDFLAGS=-L/usr/lib prior to running configure It would be nice to have configure have options for 32bit vs 64 bit compiles on 64bit systems. The plain 64bit compile works fine. _2006-Sep-29 01:12:00 by anonymous:_ {linebreak} I have the same error with sqlite-3.3.5-r1 but compiling as 64bit not 32. ---- _2006-Sep-29 01:35:55 by anonymous:_ {linebreak} go into the generated Makefile and remove -DHAVE_READLINE, or just comment out: # READLINE_FLAGS = -DHAVE_READLINE=1 -I/usr/include/readline
#f2dcdc 1573 code active 2005 Dec anonymous Shell 2005 Dec 3 3 Bad CSV output when data contains double quotes SQLite 3.2.7 emits invalid CSV when a field value contains double quotes (or at least, it's CSV that Gnumeric cannot parse). Here's an example: sqlite> create table foo (a text, b text); sqlite> insert into foo values ("hello", "world"); sqlite> insert into foo values ("mr.", "o'reilly"); sqlite> insert into foo values ('12" EP', 'blah'); sqlite> .mode csv sqlite> .output foo.csv sqlite> select * from foo; Here's what foo.csv looks like: $ cat foo.csv "hello","world" "mr.","o'reilly" "12" EP","blah" Note the ambiguous quoting on line 3. If I load this file into Gnumeric, it parses the first two lines just fine. But the last line confuses it. It appears that doubling the quote works -- at least for Gnumeric's CSV parser. That is, if I edit foo.csv to "hello","world" "mr.","o'reilly" "12"" EP","blah" then it's OK. This is basically a duplicate of [1312] and related shell problem reports, though it provides a better test case than the previous reports.
#e8e8bd 1562 warn active 2005 Dec anonymous Unknown 2005 Dec 3 1 i64 not defined in 32bit compiler Our 32-bit compiler doesn't recognize the i64 type. To force through compilation we've defined i64 as long. This seems to work but we have been experiencing failures in the VDBE module. We'd rather not revert to Sqlite2. Any suggestions? (I'll be opening a seperate ticket regarding the VDBE failure) _2005-Dec-16 01:22:41 by drh:_ {linebreak} Compile with -DSQLITE_32BIT_ROWID=1
#e8e8bd 1558 new active 2005 Dec anonymous VDBE 2005 Dec 3 4 Request more debugging info when SQL statements in progress I am sporadically receiving the error message "Can't commit transaction - SQL statements in progress." I believe my own code is at fault, not anything in SQLite, but I would appreciate help in diagnosing the problem in my code. SQLite obviously knows that I've lost track of one or more prepared statements that haven't run to completion, it isn't telling me *what* statements those are. I'm wondering if there is any way of getting that information. Armed with that knowledge, I can probably fix my code fairly quickly. Note: DRH did provide a workaround that involved recompiling with extra debugging information, which will probably help me in the short run. This feature request is aimed at making that debugging process easier for future developers. :-)
#e8e8bd 1550 new active 2005 Dec anonymous Unknown 2005 Dec 3 3 Triggers across attached databases Support for triggers across attached databases would be very nice. Example: sqlite3 db1 > CREATE TABLE Test (pk integer primary key autoincrement, Data vachar(128)not null); > ATTACH db2 AS history; > CREATE TABLE history.TestHistory (ObjectTable_fk integer not null, Action integer not null, Timestamp smalldatetime not null); > CREATE TRIGGER trTestHistoryUpdate UPDATE ON Test FOR EACH ROW BEGIN INSERT INTO TestHistory VALUES(OLD.pk, 0, CURRENT_TIMESTAMP); END; > Update Test SET Data='FooBar' WHERE pk=1; This results in the error: "SQL error: no such table: main.TestHistory" Changing the trigger to INSERT INTO history.TestHistory VALUES(OLD.pk,0,CURRENT_TIMESTAMP); results in "SQL error: near ".": syntax error". Attaching the databases in the reverse order and then create the trigger results in "SQL error: trigger trTestHistoryUpdate cannot reference objects in database db1";
#f2dcdc 1521 code active 2005 Nov anonymous Unknown 2005 Nov 3 2 ORDER BY sorts incorrectly with aliased fields When executing a SELECT call and aliasing fields that already exist in the table, sorting does not work correctly on the aliased fields. Here's a quick example: CREATE TABLE sort_table (name, name_alt); INSERT INTO sort_table (name, name_alt) VALUES ("a", "z"); INSERT INTO sort_table (name, name_alt) VALUES ("b", "y"); INSERT INTO sort_table (name, name_alt) VALUES ("c", "x"); This simple query works correctly: sqlite> SELECT name_alt FROM sort_table ORDER BY name_alt; name_alt x y z Aliasing name_alt as name throws off the sorter: sqlite> SELECT name_alt AS name FROM sort_table ORDER BY name; name z y x The results should be the same as in the first query and it works correctly in MySql. I'm trying to use this kind of query for a translation library. The only workaround I can think of is something like this: SELECT name_alt AS name, name_alt FROM sort_table ORDER BY name_alt; This works, but is not ideal. _2005-Nov-12 17:28:20 by anonymous:_ {linebreak} In cases like this you can use ordinal numbers as arguments to ORDER BY; replacing the last 'name' with '1' (no quotes) returns the correct results. ---- _2005-Nov-12 19:20:24 by anonymous:_ {linebreak} Yes, this does indeed work, and it makes for a simpler hack than my original one. This is still not the correct behavior though, and should be fixed so that a hack is not required at all. ---- _2005-Nov-13 15:36:22 by anonymous:_ {linebreak} Citing one database's behavior is interesting, but can you quote the paragraph in the SQL standard that shows the behavior you seek is correct? ---- _2005-Nov-13 17:19:37 by anonymous:_ {linebreak} Whether or not its in the SQL standard is somewhat irrelevent if you keep up to date with the mailing list. "Expected behavior", "how do all the other databases do it" and "makes sense" are often the governing factors in implementing changes to SQLite. In this case, proposing this change meets all 3 criteria. ---- _2005-Nov-13 18:03:49 by anonymous:_ {linebreak} SQLite does it one way. MySQL does it another way. Both behaviors could be argued to be correct. The SQL standard is certainly a good way to decide on a valid behavior. Besides, the way MySQL does it is not necessarily representative of "all other databases". At least list the output of a few major databases before making such an assumption. ---- _2005-Nov-13 20:22:40 by anonymous:_ {linebreak} I'm the guy who originally filed the ticket. I'm just an average guy, without the time or resources to run this on lots of different databases. The sql standards are not free, and I don't have a copy of any of them. I've also had very little luck finding information on the internet. All that said, I believe it would be difficult to argue that the current behavior in SQLite is correct. In all other cases, the aliased column is accepted as an ORDER BY field. If I didn't want to override the original field for the purposes of the query, why would I explicitly do so? On the other hand, there are good reasons for wanting to explicitly override the column, for goals that cannot otherwise be achieved without hacks. If I didn't want to override the field, I could get the desired effect by doing nothing. ---- _2005-Nov-14 00:08:30 by anonymous:_ {linebreak} This should really be taken to the mailing list; there are people there with access to many different databases and some of them own copies of the SQL standard. This issue of name resolution also touches on the concerns expressed in #1111, #1213, and #1228. ---- _2005-Nov-14 03:40:28 by anonymous:_ {linebreak} What should the following query return? SELECT name_alt AS name, * FROM sort_table ORDER BY name; Who knows - it is ambiguous. ---- _2005-Nov-14 03:57:44 by anonymous:_ {linebreak} I don't understand your point. Your example is ambiguous because there are two columns with the same name in the result set. The example in the original ticket is not ambiguous and should give the expected result. ---- _2005-Nov-14 05:08:06 by anonymous:_ {linebreak} The original query is ambiguous because you can refer to columns not explicitly mentioned in the SELECT to ORDER BY. No different from: select a, b, c from foo order by d; ---- _2005-Nov-14 13:41:32 by anonymous:_ {linebreak} Not true: SELECT name_alt AS name FROM sort_table ORDER BY name. The field referenced by ORDER BY does appear in the SELECT clause, after the AS. This is perfectly legitimate and the preferred way of sorting expressions. ---- _2005-Nov-14 14:33:21 by anonymous:_ {linebreak} "ORDER BY name" is abmiguous because it can refer to the name_alt column via the alias *OR* the original name column from sort_table. You can ORDER BY things not mentioned in the SELECT. SELECT name_alt AS name FROM sort_table ORDER BY name ---- _2005-Nov-14 16:26:42 by anonymous:_ {linebreak} Yeah, true -- but it's pretty obvious which one we're referring to, since we *explicitly* aliased the original field for the purposes of this query. ---- _2005-Nov-14 16:48:43 by anonymous:_ {linebreak} It's only obvious that you explicitly created an ambiguous column and that is undefined behaviour. Whether it happens to appear in the SELECT is not relevant. If you can demonstrate that the majority of databases support MySQL's behaviour, then that's another matter. ---- _2005-Nov-14 19:35:25 by anonymous:_ {linebreak} I just verified that this works as I expected on MySQL, PostgreSQL, and MS SQL Server. I don't have access to Oracle.
#f2dcdc 1519 code active 2005 Nov anonymous Unknown 2005 Nov 3 4 Size double with blob data on UPDATE ? I've a table with some fields and a blob field. I execute an INSERT INTO with NULL value on the blob field and then use the sqlite3_prepare with an UPDATE statement, to load a file into the blob field. The first time I execute an UPDATE over the record (without updating the blob field) the database size is doubled. Next UPDATEs over the same record doesn't seem to show the same problem. Temporary solving with a VACUUM at the end of the program.
#f2dcdc 1493 code active 2005 Oct anonymous Parser 2005 Oct 3 3 lemon: pathsearch uses wrong directory separator under Win32 The pathsearch function in lemon.c uses a semicolon (;) to separate the directories in the path. Under Win32 systems this should be a colon (:). _2005-Oct-18 09:37:10 by anonymous:_ {linebreak} --- lemon.c.orig 2005-10-18 11:27:55.753467000 +0200 +++ lemon.c 2005-10-18 11:29:11.897825400 +0200 @@ -2791,13 +2791,16 @@ { char *pathlist; char *path,*cp; + char ds; char c; extern int access(); #ifdef __WIN32__ cp = strrchr(argv0,'\\'); + ds = ';'; #else cp = strrchr(argv0,'/'); + ds = ':'; #endif if( cp ){ c = *cp; @@ -2812,7 +2815,7 @@ path = (char *)malloc( strlen(pathlist)+strlen(name)+2 ); if( path!=0 ){ while( *pathlist ){ - cp = strchr(pathlist,':'); + cp = strchr(pathlist,ds); if( cp==0 ) cp = &pathlist[strlen(pathlist)]; c = *cp; *cp = 0; ---- _2005-Oct-18 09:39:00 by anonymous:_ {linebreak} More readable version of the patch: --- lemon.c.orig 2005-10-18 11:27:55.753467000 +0200 +++ lemon.c 2005-10-18 11:29:11.897825400 +0200 @@ -2791,13 +2791,16 @@ { char *pathlist; char *path,*cp; + char ds; char c; extern int access(); #ifdef __WIN32__ cp = strrchr(argv0,'\\'); + ds = ';'; #else cp = strrchr(argv0,'/'); + ds = ':'; #endif if( cp ){ c = *cp; @@ -2812,7 +2815,7 @@ path = (char *)malloc( strlen(pathlist)+strlen(name)+2 ); if( path!=0 ){ while( *pathlist ){ - cp = strchr(pathlist,':'); + cp = strchr(pathlist,ds); if( cp==0 ) cp = &pathlist[strlen(pathlist)]; c = *cp; *cp = 0; ---- _2005-Oct-19 14:05:27 by anonymous:_ {linebreak} Cygwin and other Posix emulation layers on Windows require ':' for path separators, so you cannot blindly rely on __WIN32__ to make this determination.
#f2dcdc 1489 code active 2005 Oct anonymous 2005 Oct 3 2 Bad permissions on install-sh prevent 'make install' from completing It's a trivial problem - install-sh has incorrect permissions via CVS, resulting in 'make install' failing. Error: make installtclsh ../sqlite/tclinstaller.tcl 3.2../sqlite/install-sh -c -d /usr/local/libmake: execvp: ../sqlite/install-sh: Permission deniedmake: *** [install] Error 127 Permissions: -rw-r--r-- 1 cat other 5598 Sep 28 2001 ../sqlite/install-sh Fix: chmod 755 ../sqlite/install-sh
#f2dcdc 1485 code active 2005 Oct anonymous Unknown 2005 Oct 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 1457 code active 2005 Sep anonymous Shell 2005 Sep 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 1455 code active 2005 Sep anonymous Shell 2005 Sep 3 2 .import error: comma inside a string is read as field separator In Sqlite version 3, when you need to import data into a table you use .import. (You cannot do it with COPY). Well, if you need to import data in 'csv' format, and if there is a string in the input data that contains a inside itself, the reading is impossible since the comma is interpreted as a field separator. Example error message: "Error: There are 10 fields in file, and 8 fields were expected." To me its pretty much a nuisance, since csv format is the most usual format for the data I use, and I've got to change the separating character, or else locate and eliminate those extra commas. Hope this helps Thanks Antoni Francino afrancino@mesvilaweb.com
#f2dcdc 1428 code active 2005 Sep anonymous TclLib 2005 Sep 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 1423 new active 2005 Sep anonymous 2005 Sep drh 3 4 Binding NULL does not work as expected There's currently no way to compare to NULL with binding parameters. My suggestion is that you make "= ?" with the NULL bound parameter work like "IS NULL" and "<> ?" like "IS NOT NULL". Currently, neither this nor the normal way to bind to "IS ?" works. "IS ?" returns a syntax error even. Testcase follows. #include #include #include "sqlite3.h" int main() { sqlite3* db; sqlite3_stmt* st; const char* tail; int rc; sqlite3_open(":memory:", &db); /* create table */ sqlite3_prepare(db, "create table test(foo)", 0, &st, &tail); rc = sqlite3_step(st); assert(rc == SQLITE_DONE); rc = sqlite3_finalize(st); assert(rc == SQLITE_OK); /* insert row */ sqlite3_prepare(db, "insert into test(foo) values (null)", 0, &st, &tail); rc = sqlite3_step(st); assert(rc == SQLITE_DONE); rc = sqlite3_finalize(st); assert(rc == SQLITE_OK); /* query 1 */ rc = sqlite3_prepare(db, "select count(*) from test where foo is ?", 0, &st, &tail); if (rc != SQLITE_OK) { printf("query 1: %s\n", sqlite3_errmsg(db)); } /* query 2 */ sqlite3_prepare(db, "select count(*) from test where foo = ?", 0, &st, &tail); sqlite3_bind_null(st, 0); rc = sqlite3_step(st); assert(rc == SQLITE_ROW); printf("number of rows: %i\n", sqlite3_column_int(st, 0)); rc = sqlite3_finalize(st); assert(rc == SQLITE_OK); return 0; }
_2005-Sep-12 09:26:19 by ghaering:_ {linebreak} forgot to log in ... ---- _2005-Sep-12 09:38:22 by anonymous:_ {linebreak} The index of the sqlite3_bind_* and sqlite3_column_* is starting from 1 not 0. see http://www.sqlite.org/capi3ref.html#sqlite3_bind_null ---- _2005-Sep-12 09:49:26 by drh:_ {linebreak} I think what Gerhard is proposing is to have a new operator which can be used to compare for NULL so that it works against bound parameters even if the parameter is bound to NULL. You cannot use == for his. x=='abc' and x==123 both work, but x==NULL always fails. So saying x==:param is dangerous because if :param is bound to NULL it does not do what you really want. I have previously proposed extending the IS operator for this purpose. You can already say "x IS NULL". Why shouldn't you also be able to say "x IS 'abc'" and "x IS 123"? Then you could do things like "x IS :param" and it would work with bound parameters. I proposed this on the mailing list once, if I recall, and it was resoundingly rejected. But maybe people just didn't understand the question or the problem it was trying to resolve.
#e8e8bd 1417 new active 2005 Sep anonymous 2005 Sep drh 3 3 Fix successive access to a DB handler (unix broken thread file lock) This patch allows threads to access successively to a DB handle and remove the heavy restriction of the SQLITE_MISUSE. In case of simultaneous access, concurent threads get SQLITE_BUSY until the OsFile is unlocked. patch against os_unix.c in version 3.2.5. _2005-Sep-09 20:26:58 by drh:_ {linebreak} I do not believe this patch works. When a handle is moved between threads on a system where separate threads cannot override each others locks, then then lockInfo structure for that handle needs to be released and a new lockInfo structure suitable for the new thread needs to be allocated. There is a separate lockInfo structure for each thread/file combination so when moving a handle from one thread to another it is important to get a new lockInfo structure. ---- _2005-Sep-10 01:26:19 by anonymous:_ {linebreak} Why this lockInfo structure should need to be released for another thread? This patch resets safely the thread(a)/file combination to a thread(b)/file combination until the next move. This allows successive access to a DB handle and manage properly concurrent access with SQLITE_BUSY. ---- _2005-Sep-21 15:16:44 by drh:_ {linebreak} Suppose this patch is run on a system where threads cannot override each others locks. (Ex: RedHat 9). Two handles are opened on separate threads. This gives them different lockKey values. After opening, the handles are passed to the same thread. The first handle does "BEGIN; UPDATE ....;" but does not yet commit. The second handle then does an UPDATE. The first handle does ROLLBACK. At that point the database has likely been corrupted. ---- _2005-Sep-21 19:50:17 by anonymous:_ {linebreak} I can not suppose this because it's "impossible". This patch is not active on a system where threads cannot override each others locks: # define CHECK_THREADID(X) ( threadsOverrideEachOthersLocks>0 && check_threadid(X) ) Or if you suppose this is possible, this means that, on the current version of SQLite: *: the testThreadLockingBehavior function is wrong *: data corruption can happen on a system where threads can override each others locks All this is nonsense.
#f2dcdc 1365 code active 2005 Aug anonymous 2005 Aug 3 3 64 bit types not completely overridable The current 64 bit types in sqlite3.h and sqliteInt.h do not allow the type to be overriden using a preprocessor definition, unlike all the other base types. The current 64 bit typedefs assume that a "long long" is 64 bits - this is not guaranteed (and on PS2 it is wrong, long long is 128 bits). Here are some minor patches that should allow these types to be overriden, but keep the old behavior if they are not: ==== //sqlite-3.2.2/src/sqlite3.h#1 - sqlite-3.2.2\src\sqlite3.h ==== 81,83c81,83 < #if defined(_MSC_VER) || defined(__BORLANDC__) < typedef __int64 sqlite_int64; < typedef unsigned __int64 sqlite_uint64; --- > #ifdef INT64_TYPE > typedef INT64_TYPE sqlite_int64; > typedef unsigned INT64_TYPE sqlite_uint64; 85,86c85,93 < typedef long long int sqlite_int64; < typedef unsigned long long int sqlite_uint64; --- > # if defined(_MSC_VER) || defined(__BORLANDC__) > typedef __int64 sqlite_int64; > typedef unsigned __int64 sqlite_uint64; > # else > typedef long long int sqlite_int64; > typedef unsigned long long int sqlite_uint64; > # endif > # define INT64_TYPE sqlite_int64 > # define UINT64_TYPE sqlite_uint64 ==== sqlite-3.2.2/src/sqliteInt.h#1 - sqlite-3.2.2\src\sqliteInt.h ==== 157,163d156 < #ifndef UINT64_TYPE < # if defined(_MSC_VER) || defined(__BORLANDC__) < # define UINT64_TYPE unsigned __int64 < # else < # define UINT64_TYPE unsigned long long int < # endif < #endif 183c176 < typedef UINT64_TYPE u64; /* 8-byte unsigned integer */ --- > typedef sqlite_uint64 u64; /* 8-byte unsigned integer */ _2005-Aug-27 16:45:09 by drh:_ {linebreak} Can someone suggest a suitable #ifdef that will automatically identify a PS and do the right thing to provide a 64-bit integer type, similar to what is down for windows?
#f2dcdc 1308 code active 2005 Jun anonymous 2005 Jun 3 4 PRAGMA TABLE_INFO does not recognize attached database syntax. PRAGMA TABLE_INFO does not recognize the dbName.tableName syntax to distinguish between identically named tables in attached databases. _2005-Jun-28 17:06:51 by anonymous:_ {linebreak} The pragma command use a different syntax to select the attached database. The following should work: PRAGMA database_name.table_info(table_name) This should be fixed in the documentation. The optional database name is shown for the version number pragmas, but not for the others on the page http://www.sqlite.org/pragma.html#schema This seems to be a common and natural expectation since attached tables are referred to using the database_name.table_name syntax in queries. The documentation should be very clear that it is different for the pragma commands. ---- _2005-Jun-28 19:51:03 by anonymous:_ {linebreak} It should also be made clear whether a single pragma value applies to all attached databases, or if each attached database has its own value for the pragma.
#e8e8bd 1294 new active 2005 Jun anonymous 2005 Jun 3 3 API to get ordinal table name When a select statement returns a recordset, SQLite current implementation has an API to retrieve all column names. It is great to have an API to retrieve table names for each columns. This is especial usefull to deal with joins and dynamic queries and update the recordset on the fly. I believe MySQL has this feature. It would be great to port this feature over.
#f2dcdc 1111 code active 2005 Feb anonymous Unknown 2005 Jun 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 1264 code active 2005 May anonymous Unknown 2005 May 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 #endif
#e8e8bd 1254 new active 2005 May anonymous Pager 2005 May 3 3 better pager_cksum pager_cksum currently reads one byte every 200 bytes in a page and computes a checksum from this. Suggest changing this to reading 32-bits every 200 bytes. This will run a the same speed, but the likelyhood of detecting errors is larger, since 400% more data is used in the checksumming.
#f2dcdc 1248 code active 2005 May anonymous Unknown 2005 May 3 1 sqlite3_get_table returns garbage for BLOB data BLOB data returned by sqlite_get_table() is garbage when it contains data bytes holding '0' values. Code: Windows, 3.2.1, VC 6.0 char data[128]; for(int i = 0;i<128;i++) { data[i] = i+1; } sqlite3_exec(thedb,"CREATE TABLE test (b BLOB)",NULL,NULL,NULL); result = sqlite3_prepare(thedb,"INSERT INTO test (b) VALUES (?)",-1,&cstate,NULL); sqlite3_bind_blob(cstate,1,data,128,SQLITE_STATIC); // bind the data to the statement result = sqlite3_step(cstate); result = sqlite3_finalize(cstate); sqlite3_get_table(thedb,"SELECT * FROM test",result,rows,columns,NULL); this sqlite3_get_table() returns a properly layed out table. However, it looks like sqlite_get_table() is converting blob data to another type of data (string?) as it processes the command. The BLOB data it returns using this call is completely corrupted, due to processing '0' valued bytes as EOS characters. Instead it should be inferring BLOB data where appropriate, and returning a correct data block. As a workaround I've been using the prepare/step functions instead. However, the sqlite3_get_table() is a neccessity for many users of this library, as it allows a simple and elegant SQL query mechanism, and should be fixed ASAP to support BLOB data properly. _2005-Sep-27 01:44:39 by anonymous:_ {linebreak} sqlite3_get_table is considered legacy code, intended to make porting of sqlite2 applications (which never had to deal with BLOBs) easier. Its use in new applications is deprecated. If you need something like it that can handle BLOBs, you're best off writing a wrapper function for the prepare/step interface (you can use the sqlite3_get_table code as a template).
#e8e8bd 972 warn active 2004 Oct anonymous 2005 May 3 3 building SQLite on Irix Hi, Here are the warnings I got while building SQLite 3.0.8 on Irix 6.5 using SGI's MIPSpro 7.3.1.1m compiler. Most of the warnings are about signed/unsigned char issues (these warnings are common with commercial Unix compilers) and I'm not sure you're willing to fix them. Some other warnings should probably be fixed (unused variables, missing return values, and the like). cc-1116 cc: WARNING File = ./tool/lemon.c, Line = 2352 Non-void function "preprocess_input" (declared at line 2308) should return a value. } ^ cc-1164 cc: WARNING File = ./src/attach.c, Line = 170 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3StrNICmp(pDb->zName, pDbname->z, pDbname->n)==0 ) break; ^ cc-1515 cc: WARNING File = ./src/btree.c, Line = 1251 A value of type "char *" cannot be assigned to an entity of type "u8 *". pPage->aData = &((char*)pPage)[-pBt->pageSize]; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 1901 The variable "pBt" is set but never used. Btree *pBt; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 2005 The variable "oldPgno" is set but never used. Pgno oldPgno; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 2936 The variable "idxDiv" is set but never used. int idxDiv[NB]; /* Indices of divider cells in pParent */ ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 4186 The variable "cur" is set but never used. BtCursor cur; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 4188 The variable "maxLocal" is set but never used. int maxLocal, usableSize; ^ cc-1164 cc: WARNING File = ./src/build.c, Line = 461 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". zName = sqliteStrNDup(pName->z, pName->n); ^ cc-1164 cc: WARNING File = ./src/build.c, Line = 490 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". 0==sqlite3StrNICmp(pDb->zName, pName->z, pName->n) ){ ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 580 The variable "pIdx" is set but never used. Index *pIdx; ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 780 The variable "pz" is set but never used. char *z, **pz; ^ cc-1164 cc: WARNING File = ./src/build.c, Line = 1195 Argument of type "unsigned char *" is incompatible with parameter of type "const char *". || sqlite3KeywordCode(zIdent, j)!=TK_ID; ^ cc-1164 cc: WARNING File = ./src/build.c, Line = 1370 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeChangeP3(v, -1, pParse->sNameToken.z, n); ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 1904 The variable "pISameName" is set but never used. Index *pISameName; /* Another index with the same name */ ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 1905 The variable "pTSameName" is set but never used. Table *pTSameName; /* A table with same name as the index */ ^ cc-1515 cc: WARNING File = ./src/build.c, Line = 1948 A value of type "char *" cannot be assigned to an entity of type "const unsigned char *". nullId.z = pTab->aCol[pTab->nCol-1].zName; ^ cc-1164 cc: WARNING File = ./src/build.c, Line = 1949 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". nullId.n = strlen(nullId.z); ^ cc-1164 cc: WARNING File = ./src/build.c, Line = 2109 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeChangeP3(v, -1, pName->z, n); ^ cc-1164 cc: WARNING File = ./src/date.c, Line = 648 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". parseDateOrTime(sqlite3_value_text(argv[0]), p) ) return 1; ^ cc-1164 cc: WARNING File = ./src/date.c, Line = 651 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". parseModifier(sqlite3_value_text(argv[i]), p) ) return 1; ^ cc-1140 cc: WARNING File = ./src/date.c, Line = 764 A value of type "const unsigned char *" cannot be used to initialize an entity of type "const char *". const char *zFmt = sqlite3_value_text(argv[0]); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 286 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pExpr->iTable = i = atoi(&pToken->z[1]); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 359 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pNew->token.z = sqliteStrDup(p->token.z); ^ cc-1515 cc: WARNING File = ./src/expr.c, Line = 359 A value of type "char *" cannot be assigned to an entity of type "const unsigned char *". pNew->token.z = sqliteStrDup(p->token.z); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 375 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pTo->z = sqliteStrNDup(pFrom->z, pFrom->n); ^ cc-1515 cc: WARNING File = ./src/expr.c, Line = 375 A value of type "char *" cannot be assigned to an entity of type "const unsigned char *". pTo->z = sqliteStrNDup(pFrom->z, pFrom->n); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 573 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3GetInt32(p->token.z, pValue) ){ ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 583 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( n==0 && sqlite3GetInt32(p->token.z, pValue) ){ ^ cc-1515 cc: WARNING File = ./src/expr.c, Line = 1039 A value of type "const unsigned char *" cannot be assigned to an entity of type "const char *". *pzName = pExpr->token.z; ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1212 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". codeInteger(v, pExpr->token.z, pExpr->token.n); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1219 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeOp3(v, op, 0, 0, pExpr->token.z, pExpr->token.n); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1225 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeOp3(v, op, 0, 0, pExpr->token.z+1, pExpr->token.n-1); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1236 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeChangeP3(v, -1, pExpr->token.z, pExpr->token.n); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1466 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pExpr->token.z, pExpr->token.n); ^ cc-1552 cc: WARNING File = ./src/expr.c, Line = 1491 The variable "v" is set but never used. Vdbe *v; ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1733 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3StrNICmp(pA->token.z, pB->token.z, pB->token.n)!=0 ) return 0; ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1733 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3StrNICmp(pA->token.z, pB->token.z, pB->token.n)!=0 ) return 0; ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1805 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pExpr->token.z, pExpr->token.n, ^ cc-1140 cc: WARNING File = ./src/func.c, Line = 100 A value of type "const unsigned char *" cannot be used to initialize an entity of type "const char *". const char *z = sqlite3_value_text(argv[0]); ^ cc-1515 cc: WARNING File = ./src/func.c, Line = 151 A value of type "const unsigned char *" cannot be assigned to an entity of type "const char *". z = sqlite3_value_text(argv[0]); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 209 Argument of type "unsigned char *" is incompatible with parameter of type "char *". strcpy(z, sqlite3_value_text(argv[0])); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 209 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". strcpy(z, sqlite3_value_text(argv[0])); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 213 Argument of type "unsigned char *" is incompatible with parameter of type "const char *". sqlite3_result_text(context, z, -1, SQLITE_TRANSIENT); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 222 Argument of type "unsigned char *" is incompatible with parameter of type "char *". strcpy(z, sqlite3_value_text(argv[0])); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 222 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". strcpy(z, sqlite3_value_text(argv[0])); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 226 Argument of type "unsigned char *" is incompatible with parameter of type "const char *". sqlite3_result_text(context, z, -1, SQLITE_TRANSIENT); ^ cc-1140 cc: WARNING File = ./src/func.c, Line = 562 A value of type "const unsigned char *" cannot be used to initialize an entity of type "const char *". const char *zArg = sqlite3_value_text(argv[0]); ^ cc-1515 cc: WARNING File = ./src/main.c, Line = 876 A value of type "const unsigned char *" cannot be assigned to an entity of type "const char *". z = sqlite3_value_text(db->pErr); ^ cc-1552 cc: WARNING File = ./src/os_unix.c, Line = 1185 The variable "inMutex" is set but never used. static int inMutex = 0; ^ cc-1164 cc: WARNING File = ./src/pager.c, Line = 873 Argument of type "u8 *" is incompatible with parameter of type "const char *". if( pager_cksum(pPager, pgno, aData)!=cksum ){ ^ cc-1164 cc: WARNING File = parse.y, Line = 193 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". { yygotominor.yy284 = atoi(yymsp[0].minor.yy98.z); } ^ cc-1164 cc: WARNING File = parse.y, Line = 194 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". { yygotominor.yy284 = -atoi(yymsp[0].minor.yy98.z); } ^ cc-1164 cc: WARNING File = parse.y, Line = 215 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". {sqlite3AddCollateType(pParse, yymsp[0].minor.yy98.z, yymsp[0].minor.yy98.n);} ^ cc-1164 cc: WARNING File = parse.y, Line = 753 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( p ) p->pColl = sqlite3LocateCollSeq(pParse, yymsp[-1].minor.yy98.z, yymsp[-1].minor.yy98.n); ^ cc-1164 cc: WARNING File = parse.y, Line = 761 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( p ) p->pColl = sqlite3LocateCollSeq(pParse, yymsp[-1].minor.yy98.z, yymsp[-1].minor.yy98.n); ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 31 Argument of type "const u8 *" is incompatible with parameter of type "const char *". if( sqlite3IsNumber(z, 0, SQLITE_UTF8) ){ ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 32 Argument of type "const u8 *" is incompatible with parameter of type "const char *". return atoi(z); ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 35 Argument of type "const u8 *" is incompatible with parameter of type "const char *". if( sqlite3StrICmp(z,azTrue[i])==0 ) return 1; ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 35 Argument of type "const u8 *" is incompatible with parameter of type "const char *". if( sqlite3StrICmp(z,azTrue[i])==0 ) return 1; ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 65 Argument of type "u8 *" is incompatible with parameter of type "const char *". if( sqlite3IsNumber(z, 0, SQLITE_UTF8) ){ ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 66 Argument of type "u8 *" is incompatible with parameter of type "const char *". return atoi(z); ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 69 Argument of type "u8 *" is incompatible with parameter of type "const char *". if( sqlite3StrICmp(z,aKey[i].zWord)==0 ) return aKey[i].val; ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 69 Argument of type "const u8 *" is incompatible with parameter of type "const char *". if( sqlite3StrICmp(z,aKey[i].zWord)==0 ) return aKey[i].val; ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 158 Argument of type "const char *" is incompatible with parameter of type "const u8 *". }else if( getBoolean(zRight) ){ ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 351 Argument of type "char *" is incompatible with parameter of type "u8 *". pDb->safety_level = getSafetyLevel(zRight)+1; ^ cc-1164 cc: WARNING File = ./src/printf.c, Line = 594 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". (*func)(arg, pToken->z, pToken->n); ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 105 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". && sqlite3StrNICmp(p->z, keywords[j].zKeyword, p->n)==0 ){ ^ cc-1515 cc: WARNING File = ./src/select.c, Line = 150 A value of type "const char *" cannot be assigned to an entity of type "const unsigned char *". p->z = z; ^ cc-1515 cc: WARNING File = ./src/select.c, Line = 575 A value of type "char *" cannot be assigned to an entity of type "u8 *". pInfo->aSortOrder = (char*)&pInfo->aColl[nCol]; ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 761 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeSetColName(v, i, p->span.z, p->span.n); ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 774 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeSetColName(v, i, p->span.z, p->span.n); ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 1957 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pList->a[i].zName = sqliteStrNDup(pExpr->span.z, pExpr->span.n); ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 2060 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3StrNICmp(pExpr->token.z,"min",3)==0 ){ ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 2062 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". }else if( sqlite3StrNICmp(pExpr->token.z,"max",3)==0 ){ ^ cc-1515 cc: WARNING File = ./src/tokenize.c, Line = 427 A value of type "const char *" cannot be assigned to an entity of type "const unsigned char *". pParse->sLastToken.z = &zSql[i]; ^ cc-1164 cc: WARNING File = ./src/trigger.c, Line = 237 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeChangeP3(v, addr+6, pAll->z, pAll->n); ^ cc-1164 cc: WARNING File = ./src/trigger.c, Line = 276 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". p->target.z = sqliteStrNDup(p->target.z, p->target.n); ^ cc-1515 cc: WARNING File = ./src/trigger.c, Line = 276 A value of type "char *" cannot be assigned to an entity of type "const unsigned char *". p->target.z = sqliteStrNDup(p->target.z, p->target.n); ^ cc-1515 cc: WARNING File = ./src/trigger.c, Line = 627 A value of type "char *" cannot be assigned to an entity of type "const unsigned char *". sDb.z = pParse->db->aDb[iDb].zName; ^ cc-1164 cc: WARNING File = ./src/trigger.c, Line = 628 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sDb.n = strlen(sDb.z); ^ cc-1164 cc: WARNING File = ./src/vacuum.c, Line = 61 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". rc = execSql(db, sqlite3_column_text(pStmt, 0)); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1176 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3SetString(&p->zErrMsg, sqlite3_value_text(pTos), (char*)0); ^ cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1737 A value of type "u8 *" cannot be assigned to an entity of type "char *". zRec = pC->aRow; ^ cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1802 A value of type "char *" cannot be assigned to an entity of type "u8 *". zRec = pC->aRow = zData; ^ cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1802 A value of type "u8 *" cannot be assigned to an entity of type "char *". zRec = pC->aRow = zData; ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1807 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". idx = sqlite3GetVarint32(zData, &szHdr); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1833 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". idx += sqlite3GetVarint32(&zData[idx], &aType[i]); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1873 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". sqlite3VdbeSerialGet(zData, aType[p2], pTos); ^ cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 2018 A value of type "char *" cannot be assigned to an entity of type "unsigned char *". zNewRecord = zTemp; ^ cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 2060 A value of type "unsigned char *" cannot be assigned to an entity of type "char *". pTos->z = zNewRecord; ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 2715 Argument of type "char *" is incompatible with parameter of type "const u8 *". szRowid = sqlite3VdbeIdxRowidLen(nKey, zKey); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 2732 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". rc = sqlite3VdbeIdxKeyCompare(pCx, len, zKey, &res); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3383 Argument of type "const char *" is incompatible with parameter of type "const u8 *". len = nKey - sqlite3VdbeIdxRowidLen(nKey, zKey); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3389 Argument of type "const char *" is incompatible with parameter of type "const unsigned char *". if( sqlite3VdbeIdxKeyCompare(pC, len, zKey, &c)==SQLITE_OK && c==0 ){ ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3539 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". rc = sqlite3VdbeIdxKeyCompare(pC, pTos->n, pTos->z, &res); ^ cc-1552 cc: WARNING File = ./src/vdbe.c, Line = 3525 The variable "pCrsr" is set but never used. BtCursor *pCrsr; ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3577 Argument of type "const char *" is incompatible with parameter of type "const unsigned char *". k = sqlite3GetVarint32(z, &serial_type); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3579 Argument of type "const char *" is incompatible with parameter of type "const unsigned char *". k += sqlite3GetVarint32(&z[k], &serial_type); ^ cc-1119 cc: WARNING File = ./src/vdbeapi.c, Line = 47 The "return" expression type differs from the function return type. return (const char *)sqlite3ValueText(pVal, SQLITE_UTF8); ^ cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1746 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". sqlite3GetVarint32(m.z, &szHdr); ^ cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1747 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". sqlite3GetVarint32(&m.z[szHdr-1], &typeRowid); ^ cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1749 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". sqlite3VdbeSerialGet(&m.z[m.n-lenRowid], typeRowid, &v); ^ cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1785 Argument of type "char *" is incompatible with parameter of type "const u8 *". lenRowid = sqlite3VdbeIdxRowidLen(m.n, m.z); ^ cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 65 A value of type "u8 *" cannot be assigned to an entity of type "char *". pMem->z = z; ^ cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 85 A value of type "char *" cannot be assigned to an entity of type "u8 *". z = pMem->zShort; ^ cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 98 A value of type "u8 *" cannot be assigned to an entity of type "char *". pMem->z = z; ^ cc-1140 cc: WARNING File = ./src/vdbemem.c, Line = 154 A value of type "char *" cannot be used to initialize an entity of type "u8 *". u8 *z = pMem->zShort; ^ cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 166 Argument of type "u8 *" is incompatible with parameter of type "char *". sqlite3_snprintf(NBFS, z, "%.15g", pMem->r); ^ cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 169 Argument of type "u8 *" is incompatible with parameter of type "char *". sqlite3_snprintf(NBFS, z, "%lld", pMem->i); ^ cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 171 Argument of type "u8 *" is incompatible with parameter of type "const char *". pMem->n = strlen(z); ^ cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 172 A value of type "u8 *" cannot be assigned to an entity of type "char *". pMem->z = z; ^ cc-1515 cc: WARNING File = ./src/utf.c, Line = 274 A value of type "char *" cannot be assigned to an entity of type "unsigned char *". zIn = pMem->z; ^ cc-1515 cc: WARNING File = ./src/utf.c, Line = 310 A value of type "char *" cannot be assigned to an entity of type "unsigned char *". zIn = pMem->z; ^ cc-1515 cc: WARNING File = ./src/utf.c, Line = 362 A value of type "char *" cannot be assigned to an entity of type "unsigned char *". zOut = pMem->zShort; ^ cc-1515 cc: WARNING File = ./src/utf.c, Line = 367 A value of type "unsigned char *" cannot be assigned to an entity of type "char *". pMem->z = zOut; ^ cc-1164 cc: WARNING File = ./src/shell.c, Line = 353 Argument of type "const char *" is incompatible with parameter of type "const unsigned char *". }else if( isNumber(z, 0) ){ ^ cc-1164 cc: WARNING File = ./src/shell.c, Line = 519 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". }else if( isNumber(azArg[i], 0) ){ ^ cc-1164 cc: WARNING File = ./src/shell.c, Line = 682 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". zSelect = appendText(zSelect, sqlite3_column_text(pTableInfo, 1), '"'); ^ ld32: WARNING 84 : /usr/lib32/libcurses.so is not used for resolving any symbol. creating sqlite3 _2005-Jan-24 23:04:23 by anonymous:_ {linebreak} Hi, Here are the warnings I got while building SQLite 3.1.0 alpha on Irix 6.5 using SGI's MIPSpro 7.3.1.1m compiler. cc-1116 cc: WARNING File = ./tool/lemon.c, Line = 2352 Non-void function "preprocess_input" (declared at line 2308) should return a value. } ^ cc-1164 cc: WARNING File = ./src/attach.c, Line = 170 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3StrNICmp(pDb->zName, pDbname->z, pDbname->n)==0 ) break; ^ cc-1515 cc: WARNING File = ./src/btree.c, Line = 1494 A value of type "char *" cannot be assigned to an entity of type "u8 *". pPage->aData = &((char*)pPage)[-pBt->psAligned]; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 2444 The variable "pBt" is set but never used. Btree *pBt; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 2548 The variable "oldPgno" is set but never used. Pgno oldPgno; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 3757 The variable "idxDiv" is set but never used. int idxDiv[NB]; /* Indices of divider cells in pParent */ ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 5384 The variable "cur" is set but never used. BtCursor cur; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 5386 The variable "maxLocal" is set but never used. int maxLocal, usableSize; ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 128 The variable "rc" is set but never used. int rc; ^ cc-1164 cc: WARNING File = ./src/build.c, Line = 499 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". zName = sqliteStrNDup(pName->z, pName->n); ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 626 The variable "pIdx" is set but never used. Index *pIdx; ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 849 The variable "pz" is set but never used. char *z, **pz; ^ cc-1164 cc: WARNING File = ./src/build.c, Line = 1281 Argument of type "unsigned char *" is incompatible with parameter of type "const char *". || sqlite3KeywordCode(zIdent, j)!=TK_ID; ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 2191 The variable "pISameName" is set but never used. Index *pISameName; /* Another index with the same name */ ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 2192 The variable "pTSameName" is set but never used. Table *pTSameName; /* A table with same name as the index */ ^ cc-1515 cc: WARNING File = ./src/build.c, Line = 2235 A value of type "char *" cannot be assigned to an entity of type "const unsigned char *". nullId.z = pTab->aCol[pTab->nCol-1].zName; ^ cc-1164 cc: WARNING File = ./src/build.c, Line = 2236 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". nullId.n = strlen(nullId.z); ^ cc-1164 cc: WARNING File = ./src/build.c, Line = 2923 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pColl = sqlite3FindCollSeq(db, db->enc, pName1->z, pName1->n, 0); ^ cc-1164 cc: WARNING File = ./src/date.c, Line = 646 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". parseDateOrTime(sqlite3_value_text(argv[0]), p) ) return 1; ^ cc-1164 cc: WARNING File = ./src/date.c, Line = 649 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". parseModifier(sqlite3_value_text(argv[i]), p) ) return 1; ^ cc-1140 cc: WARNING File = ./src/date.c, Line = 762 A value of type "const unsigned char *" cannot be used to initialize an entity of type "const char *". const char *zFmt = sqlite3_value_text(argv[0]); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 226 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". depth = atoi(&pToken->z[1]); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 322 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pExpr->iTable = i = atoi(&pToken->z[1]); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 395 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pNew->token.z = sqliteStrNDup(p->token.z, p->token.n); ^ cc-1515 cc: WARNING File = ./src/expr.c, Line = 395 A value of type "char *" cannot be assigned to an entity of type "const unsigned char *". pNew->token.z = sqliteStrNDup(p->token.z, p->token.n); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 411 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pTo->z = sqliteStrNDup(pFrom->z, pFrom->n); ^ cc-1515 cc: WARNING File = ./src/expr.c, Line = 411 A value of type "char *" cannot be assigned to an entity of type "const unsigned char *". pTo->z = sqliteStrNDup(pFrom->z, pFrom->n); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 663 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3GetInt32(p->token.z, pValue) ){ ^ cc-1515 cc: WARNING File = ./src/expr.c, Line = 946 A value of type "const unsigned char *" cannot be assigned to an entity of type "const char *". *pzName = pExpr->token.z; ^ cc-1174 cc: WARNING File = ./src/expr.c, Line = 993 The variable "i" was declared but never referenced. int i; ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1402 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". codeInteger(v, pExpr->token.z, pExpr->token.n); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1409 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeOp3(v, op, 0, 0, pExpr->token.z, pExpr->token.n); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1416 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeOp3(v, op, 0, 0, pExpr->token.z+1, pExpr->token.n-1); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1428 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeChangeP3(v, -1, pExpr->token.z, pExpr->token.n); ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1673 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pExpr->token.z, pExpr->token.n); ^ cc-1552 cc: WARNING File = ./src/expr.c, Line = 1726 The variable "v" is set but never used. Vdbe *v; ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1968 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3StrNICmp(pA->token.z, pB->token.z, pB->token.n)!=0 ) return 0; ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 1968 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3StrNICmp(pA->token.z, pB->token.z, pB->token.n)!=0 ) return 0; ^ cc-1164 cc: WARNING File = ./src/expr.c, Line = 2037 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pExpr->token.z, pExpr->token.n, ^ cc-1140 cc: WARNING File = ./src/func.c, Line = 100 A value of type "const unsigned char *" cannot be used to initialize an entity of type "const char *". const char *z = sqlite3_value_text(argv[0]); ^ cc-1515 cc: WARNING File = ./src/func.c, Line = 151 A value of type "const unsigned char *" cannot be assigned to an entity of type "const char *". z = sqlite3_value_text(argv[0]); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 209 Argument of type "unsigned char *" is incompatible with parameter of type "char *". strcpy(z, sqlite3_value_text(argv[0])); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 209 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". strcpy(z, sqlite3_value_text(argv[0])); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 213 Argument of type "unsigned char *" is incompatible with parameter of type "const char *". sqlite3_result_text(context, z, -1, SQLITE_TRANSIENT); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 222 Argument of type "unsigned char *" is incompatible with parameter of type "char *". strcpy(z, sqlite3_value_text(argv[0])); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 222 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". strcpy(z, sqlite3_value_text(argv[0])); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 226 Argument of type "unsigned char *" is incompatible with parameter of type "const char *". sqlite3_result_text(context, z, -1, SQLITE_TRANSIENT); ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 479 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3utf8CharLen(zEsc, -1)!=1 ){ ^ cc-1140 cc: WARNING File = ./src/func.c, Line = 560 A value of type "const unsigned char *" cannot be used to initialize an entity of type "const char *". char const *zCsr = zSql; ^ cc-1515 cc: WARNING File = ./src/func.c, Line = 571 A value of type "const char *" cannot be assigned to an entity of type "const unsigned char *". tname.z = zCsr; ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 579 Argument of type "const char *" is incompatible with parameter of type "const unsigned char *". len = sqlite3GetToken(zCsr, &token); ^ cc-1140 cc: WARNING File = ./src/func.c, Line = 611 A value of type "const unsigned char *" cannot be used to initialize an entity of type "const char *". char const *zCsr = zSql; ^ cc-1515 cc: WARNING File = ./src/func.c, Line = 623 A value of type "const char *" cannot be assigned to an entity of type "const unsigned char *". tname.z = zCsr; ^ cc-1164 cc: WARNING File = ./src/func.c, Line = 631 Argument of type "const char *" is incompatible with parameter of type "const unsigned char *". len = sqlite3GetToken(zCsr, &token); ^ cc-1140 cc: WARNING File = ./src/func.c, Line = 713 A value of type "const unsigned char *" cannot be used to initialize an entity of type "const char *". const char *zArg = sqlite3_value_text(argv[0]); ^ cc-1515 cc: WARNING File = ./src/main.c, Line = 888 A value of type "const unsigned char *" cannot be assigned to an entity of type "const char *". z = sqlite3_value_text(db->pErr); ^ cc-1552 cc: WARNING File = ./src/os_unix.c, Line = 1217 The variable "inMutex" is set but never used. static int inMutex = 0; ^ cc-1164 cc: WARNING File = ./src/pager.c, Line = 922 Argument of type "u8 *" is incompatible with parameter of type "const char *". if( pager_cksum(pPager, pgno, aData)!=cksum ){ ^ cc-1164 cc: WARNING File = parse.y, Line = 201 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". { yygotominor.yy60 = atoi(yymsp[0].minor.yy406.z); } ^ cc-1164 cc: WARNING File = parse.y, Line = 202 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". { yygotominor.yy60 = -atoi(yymsp[0].minor.yy406.z); } ^ cc-1164 cc: WARNING File = parse.y, Line = 230 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". {sqlite3AddCollateType(pParse, yymsp[0].minor.yy406.z, yymsp[0].minor.yy406.n);} ^ cc-1164 cc: WARNING File = parse.y, Line = 804 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( p ) p->pColl = sqlite3LocateCollSeq(pParse, yymsp[-1].minor.yy406.z, yymsp[-1].minor.yy406.n); ^ cc-1164 cc: WARNING File = parse.y, Line = 812 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( p ) p->pColl = sqlite3LocateCollSeq(pParse, yymsp[-1].minor.yy406.z, yymsp[-1].minor.yy406.n); ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 47 Argument of type "const u8 *" is incompatible with parameter of type "const char *". return atoi(z); ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 49 Argument of type "const u8 *" is incompatible with parameter of type "const char *". n = strlen(z); ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 51 Argument of type "const u8 *" is incompatible with parameter of type "const char *". if( iLength[i]==n && sqlite3StrNICmp(&zText[iOffset[i]],z,n)==0 ){ ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 163 Argument of type "const char *" is incompatible with parameter of type "const u8 *". }else if( getBoolean(zRight) ){ ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 309 Argument of type "char *" is incompatible with parameter of type "const u8 *". sqlite3BtreeSetAutoVacuum(pBt, getBoolean(zRight)); ^ cc-1164 cc: WARNING File = ./src/pragma.c, Line = 417 Argument of type "char *" is incompatible with parameter of type "const u8 *". pDb->safety_level = getSafetyLevel(zRight)+1; ^ cc-1164 cc: WARNING File = ./src/printf.c, Line = 600 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". (*func)(arg, pToken->z, pToken->n); ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 105 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". && sqlite3StrNICmp(p->z, keywords[j].zKeyword, p->n)==0 ){ ^ cc-1515 cc: WARNING File = ./src/select.c, Line = 150 A value of type "const char *" cannot be assigned to an entity of type "const unsigned char *". p->z = z; ^ cc-1515 cc: WARNING File = ./src/select.c, Line = 591 A value of type "char *" cannot be assigned to an entity of type "u8 *". pInfo->aSortOrder = (char*)&pInfo->aColl[nCol]; ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 789 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeSetColName(v, i, p->span.z, p->span.n); ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 802 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeSetColName(v, i, p->span.z, p->span.n); ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 2037 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". pList->a[i].zName = sqliteStrNDup(pExpr->span.z, pExpr->span.n); ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 2140 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". if( sqlite3StrNICmp(pExpr->token.z,"min",3)==0 ){ ^ cc-1164 cc: WARNING File = ./src/select.c, Line = 2142 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". }else if( sqlite3StrNICmp(pExpr->token.z,"max",3)==0 ){ ^ cc-1515 cc: WARNING File = ./src/tokenize.c, Line = 356 A value of type "const char *" cannot be assigned to an entity of type "const unsigned char *". pParse->sLastToken.z = &zSql[i]; ^ cc-1164 cc: WARNING File = ./src/trigger.c, Line = 236 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3VdbeChangeP3(v, addr+6, pAll->z, pAll->n); ^ cc-1164 cc: WARNING File = ./src/trigger.c, Line = 275 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". p->target.z = sqliteStrNDup(p->target.z, p->target.n); ^ cc-1515 cc: WARNING File = ./src/trigger.c, Line = 275 A value of type "char *" cannot be assigned to an entity of type "const unsigned char *". p->target.z = sqliteStrNDup(p->target.z, p->target.n); ^ cc-1515 cc: WARNING File = ./src/trigger.c, Line = 612 A value of type "char *" cannot be assigned to an entity of type "const unsigned char *". sDb.z = pParse->db->aDb[iDb].zName; ^ cc-1164 cc: WARNING File = ./src/trigger.c, Line = 613 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sDb.n = strlen(sDb.z); ^ cc-1164 cc: WARNING File = ./src/vacuum.c, Line = 61 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". rc = execSql(db, sqlite3_column_text(pStmt, 0)); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1193 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". sqlite3SetString(&p->zErrMsg, sqlite3_value_text(pTos), (char*)0); ^ cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1748 A value of type "u8 *" cannot be assigned to an entity of type "char *". zRec = pC->aRow; ^ cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1815 A value of type "char *" cannot be assigned to an entity of type "u8 *". zRec = pC->aRow = zData; ^ cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 1815 A value of type "u8 *" cannot be assigned to an entity of type "char *". zRec = pC->aRow = zData; ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1820 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". idx = sqlite3GetVarint32(zData, &szHdr); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1846 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". idx += sqlite3GetVarint32(&zData[idx], &aType[i]); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 1885 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". sqlite3VdbeSerialGet(zData, aType[p2], pTos); ^ cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 2030 A value of type "char *" cannot be assigned to an entity of type "unsigned char *". zNewRecord = zTemp; ^ cc-1515 cc: WARNING File = ./src/vdbe.c, Line = 2064 A value of type "unsigned char *" cannot be assigned to an entity of type "char *". pTos->z = zNewRecord; ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 2728 Argument of type "char *" is incompatible with parameter of type "const u8 *". szRowid = sqlite3VdbeIdxRowidLen(nKey, zKey); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 2745 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". rc = sqlite3VdbeIdxKeyCompare(pCx, len, zKey, &res); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3439 Argument of type "const char *" is incompatible with parameter of type "const u8 *". len = nKey - sqlite3VdbeIdxRowidLen(nKey, zKey); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3445 Argument of type "const char *" is incompatible with parameter of type "const unsigned char *". if( sqlite3VdbeIdxKeyCompare(pC, len, zKey, &c)==SQLITE_OK && c==0 ){ ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3595 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". rc = sqlite3VdbeIdxKeyCompare(pC, pTos->n, pTos->z, &res); ^ cc-1552 cc: WARNING File = ./src/vdbe.c, Line = 3581 The variable "pCrsr" is set but never used. BtCursor *pCrsr; ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3633 Argument of type "const char *" is incompatible with parameter of type "const unsigned char *". k = sqlite3GetVarint32(z, &serial_type); ^ cc-1164 cc: WARNING File = ./src/vdbe.c, Line = 3635 Argument of type "const char *" is incompatible with parameter of type "const unsigned char *". k += sqlite3GetVarint32(&z[k], &serial_type); ^ cc-1119 cc: WARNING File = ./src/vdbeapi.c, Line = 47 The "return" expression type differs from the function return type. return (const char *)sqlite3ValueText(pVal, SQLITE_UTF8); ^ cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1747 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". sqlite3GetVarint32(m.z, &szHdr); ^ cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1748 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". sqlite3GetVarint32(&m.z[szHdr-1], &typeRowid); ^ cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1750 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". sqlite3VdbeSerialGet(&m.z[m.n-lenRowid], typeRowid, &v); ^ cc-1164 cc: WARNING File = ./src/vdbeaux.c, Line = 1786 Argument of type "char *" is incompatible with parameter of type "const u8 *". lenRowid = sqlite3VdbeIdxRowidLen(m.n, m.z); ^ cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 76 A value of type "u8 *" cannot be assigned to an entity of type "char *". pMem->z = z; ^ cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 96 A value of type "char *" cannot be assigned to an entity of type "u8 *". z = pMem->zShort; ^ cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 109 A value of type "u8 *" cannot be assigned to an entity of type "char *". pMem->z = z; ^ cc-1140 cc: WARNING File = ./src/vdbemem.c, Line = 165 A value of type "char *" cannot be used to initialize an entity of type "u8 *". u8 *z = pMem->zShort; ^ cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 177 Argument of type "u8 *" is incompatible with parameter of type "char *". sqlite3_snprintf(NBFS, z, "%.15g", pMem->r); ^ cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 180 Argument of type "u8 *" is incompatible with parameter of type "char *". sqlite3_snprintf(NBFS, z, "%lld", pMem->i); ^ cc-1164 cc: WARNING File = ./src/vdbemem.c, Line = 182 Argument of type "u8 *" is incompatible with parameter of type "const char *". pMem->n = strlen(z); ^ cc-1515 cc: WARNING File = ./src/vdbemem.c, Line = 183 A value of type "u8 *" cannot be assigned to an entity of type "char *". pMem->z = z; ^ cc-1552 cc: WARNING File = ./src/where.c, Line = 883 The variable "pTab" is set but never used. Table *pTab; /* Left-most table in the FROM clause */ ^ cc-1515 cc: WARNING File = ./src/utf.c, Line = 275 A value of type "char *" cannot be assigned to an entity of type "unsigned char *". zIn = pMem->z; ^ cc-1515 cc: WARNING File = ./src/utf.c, Line = 311 A value of type "char *" cannot be assigned to an entity of type "unsigned char *". zIn = pMem->z; ^ cc-1515 cc: WARNING File = ./src/utf.c, Line = 363 A value of type "char *" cannot be assigned to an entity of type "unsigned char *". zOut = pMem->zShort; ^ cc-1515 cc: WARNING File = ./src/utf.c, Line = 368 A value of type "unsigned char *" cannot be assigned to an entity of type "char *". pMem->z = zOut; ^ cc-1164 cc: WARNING File = ./src/shell.c, Line = 353 Argument of type "const char *" is incompatible with parameter of type "const unsigned char *". }else if( isNumber(z, 0) ){ ^ cc-1164 cc: WARNING File = ./src/shell.c, Line = 519 Argument of type "char *" is incompatible with parameter of type "const unsigned char *". }else if( isNumber(azArg[i], 0) ){ ^ cc-1164 cc: WARNING File = ./src/shell.c, Line = 682 Argument of type "const unsigned char *" is incompatible with parameter of type "const char *". zSelect = appendText(zSelect, sqlite3_column_text(pTableInfo, 1), '"'); ^ ---- _2005-Feb-13 13:59:50 by anonymous:_ {linebreak} Hi, Here are the warnings I got while building SQLite 3.1.1 beta on Irix 6.5 using SGI's MIPSpro 7.3.1.1m compiler. I've removed all the signed/unsigned issues, since I suspect you're not interested... cc-1552 cc: WARNING File = ./src/btree.c, Line = 2444 The variable "pBt" is set but never used. Btree *pBt; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 2548 The variable "oldPgno" is set but never used. Pgno oldPgno; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 3757 The variable "idxDiv" is set but never used. int idxDiv[NB]; /* Indices of divider cells in pParent */ ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 5384 The variable "cur" is set but never used. BtCursor cur; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 5386 The variable "maxLocal" is set but never used. int maxLocal, usableSize; ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 131 The variable "rc" is set but never used. int rc; ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 629 The variable "pIdx" is set but never used. Index *pIdx; ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 2238 The variable "pISameName" is set but never used. Index *pISameName; /* Another index with the same name */ ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 2239 The variable "pTSameName" is set but never used. Table *pTSameName; /* A table with same name as the index */ ^ cc-1552 cc: WARNING File = ./src/expr.c, Line = 996 The variable "pSrcList" is set but never used. SrcList *pSrcList; ^ cc-1552 cc: WARNING File = ./src/expr.c, Line = 1696 The variable "v" is set but never used. Vdbe *v; ^ cc-1552 cc: WARNING File = ./src/os_unix.c, Line = 1217 The variable "inMutex" is set but never used. static int inMutex = 0; ^ cc-1552 cc: WARNING File = ./src/vdbe.c, Line = 3586 The variable "pCrsr" is set but never used. BtCursor *pCrsr; ^ cc-1552 cc: WARNING File = ./src/where.c, Line = 899 The variable "pTab" is set but never used. Table *pTab; /* Left-most table in the FROM clause */ ^ ---- _2005-Feb-20 16:37:31 by anonymous:_ {linebreak} Hi, Here are the warnings I got while building SQLite 3.1.3 on Irix 6.5 using SGI's MIPSpro 7.3.1.1m compiler. Once again I've removed all the signed/unsigned issues, since I suspect you're not interested in them. cc-1552 cc: WARNING File = ./src/btree.c, Line = 2425 The variable "pBt" is set but never used. Btree *pBt; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 2529 The variable "oldPgno" is set but never used. Pgno oldPgno; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 3741 The variable "idxDiv" is set but never used. int idxDiv[NB]; /* Indices of divider cells in pParent */ ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 5372 The variable "cur" is set but never used. BtCursor cur; ^ cc-1552 cc: WARNING File = ./src/btree.c, Line = 5374 The variable "maxLocal" is set but never used. int maxLocal, usableSize; ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 133 The variable "rc" is set but never used. int rc; ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 631 The variable "pIdx" is set but never used. Index *pIdx; ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 2244 The variable "pISameName" is set but never used. Index *pISameName; /* Another index with the same name */ ^ cc-1552 cc: WARNING File = ./src/build.c, Line = 2245 The variable "pTSameName" is set but never used. Table *pTSameName; /* A table with same name as the index */ ^ cc-1552 cc: WARNING File = ./src/expr.c, Line = 1021 The variable "pSrcList" is set but never used. SrcList *pSrcList; ^ cc-1552 cc: WARNING File = ./src/expr.c, Line = 1721 The variable "v" is set but never used. Vdbe *v; ^ cc-1552 cc: WARNING File = ./src/where.c, Line = 899 The variable "pTab" is set but never used. Table *pTab; /* Left-most table in the FROM clause */ ^
#f2dcdc 1223 code active 2005 Apr anonymous 2005 Apr 3 4 .read FILENAME fails on win xp with an uft-8 encoded file saved by notepad : "SQLerror:near "´╗┐": syntax error" sqlite-3_2_1 (precompiled binaries for windows). _2005-Apr-26 12:33:32 by drh:_ {linebreak} Without some additional hints (such as the text of the file containing the syntax error) we cannot diagnose this problem. ---- _2005-Apr-26 14:55:33 by anonymous:_ {linebreak} to produce the problem : from win use notepad, enter any valid sql, save as with encoding utf8 (the file begin with the utf8 BOM &ef &bb &bf), from sqlit3 use the .read and you get it ...
#f2dcdc 1213 code active 2005 Apr anonymous Parser 2005 Apr 3 2 Problem with alias columns in subqueries The following query create an SQL error while it seems to me to be SQL complient (in fact it works fine with a lot database servers): sqlite> select i from (select 0 as i union all select 1) as tmp; SQL error: no such column: i I found a workaround writting the following SQL query (it works well if you explicits the implicit variable i) : select i from (select 0 as i union all select 1 as i) as tmp; Thanks for your help Jerome _2005-Apr-17 11:03:52 by anonymous:_ {linebreak} SQLite appears to take the column names from the last clause in a UNION (your originally query works if you reverse the order of the clauses). IIRC, the standard says that the column names in a UNION of clauses with different column names is DBMS-dependent and while many DBMSs take them from the first clause, this is not something to count on. ---- _2005-Apr-18 19:53:09 by anonymous:_ {linebreak} You're perfectly right, but it seems to me that it should be better that sqlite do respect the "de facto" standard.
#e8e8bd 1209 doc active 2005 Apr anonymous Unknown 2005 Apr anonymous 3 5 SQLite3_Free_Table returns not #SQLITE_OK if suceeds Using the function SQLITE3_Get_Table I get back a pointer to memory where the data table is stored. After reading this table I try to free the memory under use of command SQLITE3_Free_Table (using Windows DLL V3.2.1). I expect that, if freeing succeds, the answer "#SQLITE_OK". But instead I get mostly #SQLITE_ERROR, but sometimes very big numbers. In fact I checked the memory usage of my program. When I use SQLITE_Free_Table with a wrong pointer, the answer of DLL is #SQLITE_OK while the memory usage of my program increases. Whe I use the correct pointer the answer of SQLITE3_Free_Table us #SQLITE_ERROR, but the memory usage of my program remains the same as before the SQLITE3_Get_Table command. For me it seems as if the answer for the "free" command is not correct.
#f2dcdc 1205 code active 2005 Apr anonymous Unknown 2005 Apr 3 1 accent ecu etc. in connectionstring Hi Whenever I use a accent grave or accent ecu or whatever accented characters in the connectionstring sqlite turns this into weird characters (in the file name of the database. Since my database name is dependent on user input I can't eliminate this situation... bart@arlanet.com _2005-Apr-13 12:16:08 by drh:_ {linebreak} What version of SQLite? What operating system? ---- _2005-Apr-14 12:22:32 by anonymous:_ {linebreak} Windows 2000 (dutch version) Sqlite version 3. the word privé in the connectionstring becomes privé.db3 on the disk, which causes errors afterwards when opening the database ---- _2005-Apr-14 12:23:06 by anonymous:_ {linebreak} I see something goes wrong with the accents as well on the previous remark ---- _2005-Apr-14 12:29:41 by anonymous:_ {linebreak} It really sounds to me like you're taking an accented character encoded in ISO8859-1 or some similar single-byte encoding and feeding it to something that's expecting a UTF-8 encoded string. In UTF-8, any byte that has its high bit set *must* be part of a multi-byte sequence. ---- _2005-Apr-14 14:00:56 by anonymous:_ {linebreak} After converting my string to an UTF8 encoded string, it still does the same thing.... ---- _2005-Apr-14 14:06:41 by anonymous:_ {linebreak} using sqlite.net
#e8e8bd 1187 build active 2005 Mar anonymous Parser 2005 Mar drh 3 3 OMIT_TRIGGER OMIT_VIEW do not compile properly SQLITE_OMIT_TRIGGER and SQLITE_OMIT_VIEW are needed by lemon to process parse.y{linebreak} They are not passed from CFLAGS to Makefile.in OPTS.
#f2dcdc 1134 code active 2005 Feb anonymous 2005 Feb 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.
#e8e8bd 1123 build active 2005 Feb anonymous TclLib 2005 Feb 3 4 cannot find tcl.h Apparently in the new version the tcl.h (and maybe other files of tcl) is needed by default. So if you configure without any options, it will need tcl.h but the configuration script will not check for it. So the compilation will fail. The workaround is one of two: 1. Install the tcl-devel (so you have the headers like tcl.h installed) 2. run configure with --disable-tclI could not find any documentation related to it. This is new problem - I had no problems compile the former release just by running configure without options. _2005-Feb-21 11:19:55 by drh:_ {linebreak} The change to compile TCL by default appeared in 3.1.0. ---- _2005-Jul-28 02:50:05 by anonymous:_ {linebreak} _:I found another simple method to resolve the problem,if you needn't tcl interface.Just remove the tclsqlite.c from the project,then all is ok.
#f2dcdc 1112 code active 2005 Feb anonymous 2005 Feb 3 4 make test failures (108 out of 19721) on AIX 5.2, Power5 CPU Platform is an IBM p5-570 running AIX 5.2. sqlite built with CC=xlc ./configure --enable-shared=NO --disable-shared \ --enable-static=YES \ --enable-tempstore \ --enable-threads=POSIX \ --enable-tempdb-in-ram and GNU make. 'make test' ends with '108 errors out of 19721 tests'. Here are the lines that did not end with Ok: attach2-4.12... Expected: [0 {}] Got: [1 {disk I/O error}] attach2-4.15... Expected: [1 2 1 2] Got: [1 2] attach2-5.2... Error: disk I/O error autovacuum-ioerr-5.56.3... Expected: [1] Got: [0] bigfile-1.2... Error: file is encrypted or is not a database bigfile-1.3... Error: file is encrypted or is not a database bigfile-1.4... Error: file is encrypted or is not a database bigfile-1.5... Error: file is encrypted or is not a database bigfile-1.6... Error: file is encrypted or is not a database bigfile-1.7... Error: file is encrypted or is not a database bigfile-1.8... Error: file is encrypted or is not a database bigfile-1.9... Error: file is encrypted or is not a database bigfile-1.10... Error: file is encrypted or is not a database bigfile-1.11... Error: file is encrypted or is not a database bigfile-1.12... Error: file is encrypted or is not a database bigfile-1.13... Error: file is encrypted or is not a database bigfile-1.14... Error: file is encrypted or is not a database bigfile-1.15... Error: file is encrypted or is not a database bigfile-1.16... Error: file is encrypted or is not a database ioerr-5.53.3... Expected: [1] Got: [0] misc4-5.2... Expected: [a 1 b 2 a:1 1 c 3] Got: [] misc4.test did not close all files: 1 notnull.test did not close all files: 1 null.test did not close all files: 1 pager.test did not close all files: 1 pager2.test did not close all files: 1 pager3.test did not close all files: 1 pagesize.test did not close all files: 1 pragma.test did not close all files: 1 printf.test did not close all files: 1 progress.test did not close all files: 1 quote.test did not close all files: 1 reindex.test did not close all files: 1 rollback.test did not close all files: 1 rowid.test did not close all files: 1 safety.test did not close all files: 1 schema.test did not close all files: 1 select1.test did not close all files: 2 time with cache: 895550 microseconds per iteration time without cache: 2262076 microseconds per iteration select2.test did not close all files: 2 select3.test did not close all files: 2 select4.test did not close all files: 2 select5.test did not close all files: 2 select6.test did not close all files: 2 select7.test did not close all files: 2 sort.test did not close all files: 2 subquery.test did not close all files: 2 subselect.test did not close all files: 2 table-8.1... Expected: [desc a asc b key 9 14_vac 0 fuzzy_dog_12 xyz begin hi end y'all] Got: [] table-8.1.1... Expected: [{CREATE TABLE t2( "desc" text, "asc" text, "key" int, "14_vac" boolean, fuzzy_dog_12 varchar(10), "begin" blob, "end" clob )}] Got: [] table-8.3... Expected: [cnt 1 max(b+c) 5] Got: [] table-8.3.1... Expected: [{CREATE TABLE "t4""abc"(cnt,"max(b+c)")}] Got: [] table-8.4... Expected: [y'all 1] Got: [] table-8.5... Error: no such table: t4"abc table-8.6... Error: no such table: t2 table.test did not close all files: 3 tableapi.test did not close all files: 3 tclsqlite.test did not close all files: 3 temptable.test did not close all files: 3 thread1.test did not close all files: 3 trace.test did not close all files: 3 trans-6.1... Expected: [a 1 b 2 c 3] Got: [] trans-6.3... Expected: [p 1 q 2 r 3] Got: [] trans-6.4... Expected: [a 4 b 5 c 6] Got: [] trans-6.5... Expected: [p 1 q 2 r 3] Got: [] trans-6.6... Expected: [a 4 b 5 c 6] Got: [] trans-6.7... Expected: [1 {no such table: t1}] Got: [1 {cannot commit - no transaction is active}] trans-6.10... Error: table t1 already exists trans-6.12... Expected: [p 1 q 2 r 3] Got: [] trans-6.13... Expected: [a 4 b 5 c 6] Got: [] trans-6.14... Expected: [p 1 q 2 r 3] Got: [] trans-6.15... Expected: [a 4 b 5 c 6] Got: [] trans-6.16... Expected: [1 {no such table: t1}] Got: [1 {cannot commit - no transaction is active}] trans-6.20... Error: table t1 already exists trans-6.21... Expected: [4 -5 -6 1 -2 -3] Got: [] trans-6.22... Expected: [1 -2 -3 4 -5 -6] Got: [] trans-6.23... Expected: [4 -5 -6 1 -2 -3] Got: [] trans-6.24... Expected: [4 -5 -6 1 -2 -3] Got: [] trans-6.25... Expected: [1 -2 -3 4 -5 -6] Got: [] trans-6.26... Expected: [4 -5 -6 1 -2 -3] Got: [] trans-6.27... Expected: [4 -5 -6 1 -2 -3] Got: [] trans-6.28... Expected: [1 -2 -3 4 -5 -6] Got: [] trans.test did not close all files: 4 trigger-10.3... Error: disk I/O error trigger-10.7... Error: disk I/O error trigger-10.10... Error: disk I/O error trigger-10.11... Expected: [main 21 22 23 temp 24 25 26 aux 27 28 29] Got: [main 21 22 23] trigger1.test did not close all files: 4 trigger2.test did not close all files: 4 trigger3.test did not close all files: 4 trigger4.test did not close all files: 4 trigger5.test did not close all files: 4 trigger6.test did not close all files: 4 types.test did not close all files: 4 types2.test did not close all files: 4 unique.test did not close all files: 4 update.test did not close all files: 4 vacuum.test did not close all files: 4 varint.test did not close all files: 4 view-3.3... Expected: [xyz 2 pqr 7 c-b 1] Got: [] view-3.4... Expected: [b 2 b 3 b 5 b 6] Got: [] view-3.5... Expected: [y 2 y 3 y 5 y 6] Got: [] view-8.1... Error: no such column: pqr view-8.2... Error: no such table: v6 view-8.3... Error: no such table: main.v6 view-8.6... Error: no such table: v6 view-8.7... Error: no such table: v6 view.test did not close all files: 5 where.test did not close all files: 5 108 errors out of 19721 tests Failures on these tests: attach2-4.12 attach2-4.15 attach2-5.2 autovacuum-ioerr-5.56.3 bigfile-1.2 bigfile-1.3 bigfile-1.4 bigfile-1.5 bigfile-1.6 bigfile-1.7 bigfile-1.8 bigfile-1.9 bigfile-1.10 bigfile-1.11 bigfile-1.12 bigfile-1.13 bigfile-1.14 bigfile-1.15 bigfile-1.16 ioerr-5.53.3 misc4-5.2 misc4.test notnull.test null.test pager.test pager2.test pager3.test pagesize.test pragma.test printf.test progress.test quote.test reindex.test rollback.test rowid.test safety.test schema.test select1.test select2.test select3.test select4.test select5.test select6.test select7.test sort.test subquery.test subselect.test table-8.1 table-8.1.1 table-8.3 table-8.3.1 table-8.4 table-8.5 table-8.6 table.test tableapi.test tclsqlite.test temptable.test thread1.test trace.test trans-6.1 trans-6.3 trans-6.4 trans-6.5 trans-6.6 trans-6.7 trans-6.10 trans-6.12 trans-6.13 trans-6.14 trans-6.15 trans-6.16 trans-6.20 trans-6.21 trans-6.22 trans-6.23 trans-6.24 trans-6.25 trans-6.26 trans-6.27 trans-6.28 trans.test trigger-10.3 trigger-10.7 trigger-10.10 trigger-10.11 trigger1.test trigger2.test trigger3.test trigger4.test trigger5.test trigger6.test types.test types2.test unique.test update.test vacuum.test varint.test view-3.3 view-3.4 view-3.5 view-8.1 view-8.2 view-8.3 view-8.6 view-8.7 view.test where.test
#f2dcdc 1100 code active 2005 Feb anonymous 2005 Feb 3 3 make test segfaults at capi2-7.12 on amd64 system System is Gentoo Linux 2004.1 on Opteron processor; gcc v3.3.3, creating 64 bit binaries. Here is a traceback: capi2-7.11... Ok capi2-7.11a... Ok capi2-7.12... Program received signal SIGSEGV, Segmentation fault. 0x0000002a95b25830 in strlen () from /lib/libc.so.6 (gdb) where #0 0x0000002a95b25830 in strlen () from /lib/libc.so.6 #1 0x000000000043991c in sqlite3VdbeList (p=0x5aab60) at src/vdbeaux.c:528 #2 0x0000000000438737 in sqlite3_step (pStmt=0x13000a6023d0064) at src/vdbeapi.c:207 #3 0x0000000000416a80 in test_step (clientData=0x13000a6023d0064, interp=0x55a450, objc=0, objv=0x4) at src/test1.c:2070 #4 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so #5 0x0000002a956ba181 in TclCompEvalObj () from /usr/lib/libtcl8.4.so #6 0x0000002a956b9648 in TclCompEvalObj () from /usr/lib/libtcl8.4.so #7 0x0000002a956e4f66 in TclObjInterpProc () from /usr/lib/libtcl8.4.so #8 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so #9 0x0000002a956982d8 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so #10 0x0000002a95698097 in Tcl_EvalTokensStandard () from /usr/lib/libtcl8.4.so #11 0x0000002a95698273 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so #12 0x0000002a95698767 in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so #13 0x0000002a956e4a93 in Tcl_UplevelObjCmd () from /usr/lib/libtcl8.4.so #14 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so #15 0x0000002a956ba181 in TclCompEvalObj () from /usr/lib/libtcl8.4.so #16 0x0000002a956b9648 in TclCompEvalObj () from /usr/lib/libtcl8.4.so #17 0x0000002a956e4f66 in TclObjInterpProc () from /usr/lib/libtcl8.4.so #18 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so #19 0x0000002a956982d8 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so #20 0x0000002a95698767 in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so #21 0x0000002a956e4a93 in Tcl_UplevelObjCmd () from /usr/lib/libtcl8.4.so #22 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so #23 0x0000002a956ba181 in TclCompEvalObj () from /usr/lib/libtcl8.4.so #24 0x0000002a956b9648 in TclCompEvalObj () from /usr/lib/libtcl8.4.so #25 0x0000002a95698815 in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so #26 0x0000002a9569c486 in Tcl_CatchObjCmd () from /usr/lib/libtcl8.4.so #27 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so #28 0x0000002a956ba181 in TclCompEvalObj () from /usr/lib/libtcl8.4.so #29 0x0000002a956b9648 in TclCompEvalObj () from /usr/lib/libtcl8.4.so #30 0x0000002a95698815 in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so #31 0x0000002a9569ef7e in Tcl_IfObjCmd () from /usr/lib/libtcl8.4.so #32 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so #33 0x0000002a956ba181 in TclCompEvalObj () from /usr/lib/libtcl8.4.so #34 0x0000002a956b9648 in TclCompEvalObj () from /usr/lib/libtcl8.4.so #35 0x0000002a956e4f66 in TclObjInterpProc () from /usr/lib/libtcl8.4.so #36 0x0000002a956978fe in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so #37 0x0000002a956982d8 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so #38 0x0000002a956d1e41 in Tcl_FSEvalFile () from /usr/lib/libtcl8.4.so #39 0x0000002a956d120e in Tcl_EvalFile () from /usr/lib/libtcl8.4.so #40 0x0000000000424641 in main (argc=2, argv=0x7fbffff138) at src/tclsqlite.c:1744 (gdb) _2005-Feb-04 23:11:02 by anonymous:_ {linebreak} Some more information from a gdb session (I added the printf at line 527 and recompiled; the line numbers below will be off by one from the stack trace above): (gdb) up #1 0x000000000043996d in sqlite3VdbeList (p=0x5aab60) at src/vdbeaux.c:529 529 pMem->n = strlen(pMem->z); (gdb) list 525,535 525 526 pMem->flags = MEM_Static|MEM_Str|MEM_Term; 527 printf("src/vdbeaux.c sqlite3VdbeList pOp->opcode= %d\n", pOp->opcode); 528 pMem->z = sqlite3OpcodeNames[pOp->opcode]; /* Opcode */ 529 pMem->n = strlen(pMem->z); 530 pMem->type = SQLITE_TEXT; 531 pMem->enc = SQLITE_UTF8; 532 pMem++; 533 534 pMem->flags = MEM_Int; 535 pMem->i = pOp->p1; /* P1 */ (gdb) p pOp->opcode $1 = 40 '(' (gdb) p pMem->z $2 = 0x175002100200173
#e8e8bd 1031 new active 2004 Dec anonymous 2005 Jan 3 4 sqlite command line does not allow intermixing of dot commands and sql Dot commands are not fully intermixable with sql commands in sqlite3. Please see bug 1030.
#f2dcdc 969 code new 2004 Oct anonymous TclLib 2005 Jan 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 1058 code active 2005 Jan anonymous BTree 2005 Jan 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 1056 code active 2004 Dec anonymous Shell 2004 Dec 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
#f2dcdc 1053 code active 2004 Dec anonymous Pager 2004 Dec 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.
#e8e8bd 1043 doc active 2004 Dec anonymous 2004 Dec 3 3 SQLITE3_ANY does not exist The file "www/capi3.tcl" refers to SQLITE3_encodings, such as SQLITE3_UTF8. In the header file, these are prefixed with SQLITE_ and not SQLITE3_.
#f2dcdc 1026 code active 2004 Dec anonymous Unknown 2004 Dec 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]))
#e8e8bd 965 new active 2004 Oct anonymous VDBE 2004 Oct 3 3 Busy Handler not invoked for SELECT et.al. in SQLite <= 2.8.15 There exist very rare cases when sqlite_exec() can return SQLITE_BUSY but the user-provided busy handler although set with sqlite_busy_handler() was never invoked. Please consider the following patch against vdbe.c. It primarily affects SELECT statements. For PRAGMA similar code snippets might be necessary for the VDBE opcodes ReadCookie/SetCookie. --- sqlite.orig/src/vdbe.c Mon Jul 19 21:30:50 2004 +++ sqlite/src/vdbe.c Tue Oct 19 14:45:11 2004 @@ -2325,8 +2325,11 @@ */ case OP_VerifyCookie: { int aMeta[SQLITE_N_BTREE_META]; + int busy = 1; assert( pOp->p1>=0 && pOp->p1nDb ); - rc = sqliteBtreeGetMeta(db->aDb[pOp->p1].pBt, aMeta); + while( (rc = sqliteBtreeGetMeta(db->aDb[pOp->p1].pBt,aMeta))==SQLITE_BUSY + && db->xBusyCallback + && db->xBusyCallback(db->pBusyArg, "", busy++)!=0 ){} if( rc==SQLITE_OK && aMeta[1]!=pOp->p2 ){ sqliteSetString(&p->zErrMsg, "database schema has changed", (char*)0); rc = SQLITE_SCHEMA;
#e8e8bd 960 doc active 2004 Oct anonymous 2004 Oct 3 2 Make archive unpack into directory sqlite-VERSION/ Please make the sqlite to unpack to separate directory, so that upgrading won't overwrite previous sources. sqlite-3.0.7.tar.gz Should unpack all files under: sqlite-3.0.7/ This is the de facto format for all internet projects,
#e8e8bd 947 warn active 2004 Oct anonymous Unknown 2004 Oct 3 3 Cygwin: integer constant is too large for "long" type During porting to Cygwin, following is displayed ... gcc -DOS_WIN=1 -DHAVE_USLEEP=1 -I. -I/cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src -DNDEBUG -c /cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/util.c -DPIC -o .libs/util.o /cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/util.c: In function `sqlite3PutVarint': /cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/util.c:861: warning: integer constant is too large for "long" type _2004-Oct-06 22:18:17 by anonymous:_ {linebreak} [Forgot to paste this too] gcc -DOS_WIN=1 -DHAVE_USLEEP=1 -I. -I/cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src -DNDEBUG -c /cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/vdbe.c -DPIC -o .libs/vdbe.o {linebreak} /cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/vdbe.c: In function `sqlite3VdbeExec': {linebreak} /cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/vdbe.c:2890: warning: integer constant is too large for "long" type {linebreak} /cygdrive/e/home/jaalto/tmp/tmp/tmp/sqlite-3.0.7/src/vdbe.c:2897: warning: integer constant is too large for "long" type ---- _2004-Oct-07 03:54:36 by dougcurrie:_ {linebreak} This is a duplicate of ticket #828 Are there any issues with using the LL suffix on these constants?
#f2dcdc 923 code active 2004 Sep anonymous 2004 Sep anonymous 3 2 Missing quotes in 2.8.15 .dump cause data loss when loading in sqlite3 When converting a database by means of the command: sqlite old.db .dump | sqlite3 new.db the content of char/varchar fields is dumped by sqlite without quotes (e.g. 00001) and then when reloaded by sqlite3 it looses the heading zeroes (i.e. becomes '1', which is a really different thing for an alphanumeric field). This could be solved by a new release (sqlite 2.8.16 ?) which add quotes to alphanumeric fields (as sqlite3 does), or by a filter script that adds the quotes to the sqlite2 .dump output (I used a quick and dirty perl script to fix my dump...). _2005-Jul-11 20:08:11 by anonymous:_ {linebreak} This does not appear to be solved in sqlite 2.8.16.
#e8e8bd 843 new active 2004 Aug anonymous Unknown 2004 Aug 3 3 Introducing I64 printf size prefix sqlite3_mprintf supports the _ll_ size prefix, so int64 can be formatted using the %llu format specifier. VC++ printf routines doesn't support the _ll_ size prefix but use the _I64_ prefix, so a int64 must be formatted as %I64d or %I64u I think that sqlite3_mprintf should support both size prefixes, so a developer could use the same prefix independently to the function he will use (sqlite3_mprintf, printf, Format, etc....)
#f2dcdc 841 code active 2004 Aug anonymous Unknown 2004 Aug 3 2 inner group by query isn't honored by outer count(*) aggregate CREATE TEMP TABLE A(a int NOT NULL, b int NOT NULL, c int NOT NULL); INSERT INTO A VALUES (1, 1, 1); INSERT INTO A VALUES (1, 2, 1); INSERT INTO A VALUES (2, 1, 1); -- typical behaviour is for this to behave like the DISTINCT query below -- but instead it shows a=1 as having occured twice (but it was grouped in the inner query) SELECT a, count(*) FROM ( SELECT a, c FROM A GROUP BY 1, 2) GROUP BY a; Result: 2|1 1|2 -- shows a=1 as having occured once (correctly) SELECT a, count(*) FROM ( SELECT DISTINCT a, c FROM A) GROUP BY a; Result: 2|1 1|1 -- the top query performs better, which is why I am reporting this bug _2004-Aug-08 18:42:00 by drh:_ {linebreak} SQLite ignores the ORDER BY clause if there are no aggregate functions.
#e8e8bd 828 warn active 2004 Jul anonymous Unknown 2004 Jul 3 3 integer constants to long when compiling sqlite3 on windows using msys/mingw I get the following warnings: src/util.c: In function `sqlite3PutVarint':{linebreak} src/util.c:1022: warning: integer constant is too large for "long" type{linebreak} src/vdbe.c: In function `sqlite3VdbeExec':{linebreak} src/vdbe.c:2917: warning: integer constant is too large for "long" type{linebreak} src/vdbe.c:2924: warning: integer constant is too large for "long" type{linebreak} src/vdbeaux.c: In function `sqlite3VdbeSerialType':{linebreak} src/vdbeaux.c:1440: warning: integer constant is too large for "long" type{linebreak} src/vdbeaux.c:1440: warning: integer constant is too large for "long" type{linebreak} _2004-Aug-30 16:06:52 by anonymous:_ {linebreak} I had the same problem in Solaris. ---- _2004-Dec-09 09:31:46 by anonymous:_ {linebreak} I have the same problem compiling Sqlite 3.0.8 on Mac OS X 10.3.6. I got rid of the warnings by added the LL suffix to the offending constants. Since the line numbers producing the warnings have changed over time, below is a list that includes the statements, which might help the Sqlite developer looking for them in the current code: vdbeaux.c:1496: integer constant is too large for "long" type vdbeaux.c:1496: integer constant is too large for "long" type if( i>=-140737488355328L && i<=140737488355328L ) return 5; vdbe.c:2867: integer constant is too large for "long" type if( v==0x7fffffffffffffff ){ vdbe.c:2874: integer constant is too large for "long" type if( v==0x7fffffffffffffff ){ util.c:799: integer constant is too large for "long" type if( v & 0xff00000000000000 ){
#f2dcdc 783 code active 2004 Jun anonymous Unknown 2004 Jun 3 3 Build on MAC with -DSQLITE_DEBUG=1 compile error MacOS 10.3.4 gcc 3.3 Compileing with -DSQLITE_DEBUG=1 gives following error ./libtool --mode=compile gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DSQLITE_DEBUG=1 -I. -I../sqlite/src -DTHREADSAFE=0 -c ../sqlite/src/os_unix.c gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DSQLITE_DEBUG=1 -I. -I../sqlite/src -DTHREADSAFE=0 -c ../sqlite/src/os_unix.c -fno-common -DPIC -o .libs/os_unix.o ../sqlite/src/os_unix.c: In function `sqlite3OsRead': ../sqlite/src/os_common.h:31: error: inconsistent operand constraints in an `asm' make: *** [os_unix.lo] Error 1
#e8e8bd 780 warn active 2004 Jun anonymous Unknown 2004 Jun 3 2 Builkd gice src code errors on MacOS Building/testing MacOSX 10.3.4 gcc 3.3 Building sqlite & test gave error "constant too long for long" util.c line 1180 vdbe.c lines 2979 and 2986 vdbeaux.c line 1482 (twice) running full test gave following errors printf-1.11.1... Expected: [Three integers: -2 fffffffffffffffe 1777777777777777777776] Got: [Three integers: -1 fffffffffffffffe 1777777777777777777776] printf-1.11.2... Expected: [Three integers: ( -2) (fffffffffffffffe) (1777777777777777777776)] Got: [Three integers: ( -1) (fffffffffffffffe) (1777777777777777777776)] printf-1.11.3... Expected: [Three integers: (-2 ) (fffffffffffffffe) (1777777777777777777776)] Got: [Three integers: (-1 ) (fffffffffffffffe) (1777777777777777777776)] printf-1.11.4... Expected: [Three integers: ( -2) (fffffffffffffffe) (1777777777777777777776)] Got: [Three integers: ( -1) (fffffffffffffffe) (1777777777777777777776)] printf-1.11.5... Expected: [Three integers: (-00002) (fffffffffffffffe) (1777777777777777777776)] Got: [Three integers: (-00001) (fffffffffffffffe) (1777777777777777777776)] printf-1.11.6... Expected: [Three integers: ( -2) (fffffffffffffffe) (1777777777777777777776)] Got: [Three integers: ( -1) (fffffffffffffffe) (1777777777777777777776)] printf-1.12.1... Expected: [Three integers: -5 fffffffffffffffb 1777777777777777777773] Got: [Three integers: -1 fffffffffffffffb 1777777777777777777773] printf-1.12.2... Expected: [Three integers: ( -5) (fffffffffffffffb) (1777777777777777777773)] Got: [Three integers: ( -1) (fffffffffffffffb) (1777777777777777777773)] printf-1.12.3... Expected: [Three integers: (-5 ) (fffffffffffffffb) (1777777777777777777773)] Got: [Three integers: (-1 ) (fffffffffffffffb) (1777777777777777777773)] printf-1.12.4... Expected: [Three integers: ( -5) (fffffffffffffffb) (1777777777777777777773)] Got: [Three integers: ( -1) (fffffffffffffffb) (1777777777777777777773)] printf-1.12.5... Expected: [Three integers: (-00005) (fffffffffffffffb) (1777777777777777777773)] Got: [Three integers: (-00001) (fffffffffffffffb) (1777777777777777777773)] printf-1.12.6... Expected: [Three integers: ( -5) (fffffffffffffffb) (1777777777777777777773)] Got: [Three integers: ( -1) (fffffffffffffffb) (1777777777777777777773)] printf-1.13.1... Expected: [Three integers: -10 fffffffffffffff6 1777777777777777777766] Got: [Three integers: -1 fffffffffffffff6 1777777777777777777766] printf-1.13.2... Expected: [Three integers: ( -10) (fffffffffffffff6) (1777777777777777777766)] Got: [Three integers: ( -1) (fffffffffffffff6) (1777777777777777777766)] printf-1.13.3... Expected: [Three integers: (-10 ) (fffffffffffffff6) (1777777777777777777766)] Got: [Three integers: (-1 ) (fffffffffffffff6) (1777777777777777777766)] printf-1.13.4... Expected: [Three integers: ( -10) (fffffffffffffff6) (1777777777777777777766)] Got: [Three integers: ( -1) (fffffffffffffff6) (1777777777777777777766)] printf-1.13.5... Expected: [Three integers: (-00010) (fffffffffffffff6) (1777777777777777777766)] Got: [Three integers: (-00001) (fffffffffffffff6) (1777777777777777777766)] printf-1.13.6... Expected: [Three integers: ( -10) (fffffffffffffff6) (1777777777777777777766)] Got: [Three integers: ( -1) (fffffffffffffff6) (1777777777777777777766)] printf-1.14.1... Expected: [Three integers: -99 ffffffffffffff9d 1777777777777777777635] Got: [Three integers: -1 ffffffffffffff9d 1777777777777777777635] printf-1.14.2... Expected: [Three integers: ( -99) (ffffffffffffff9d) (1777777777777777777635)] Got: [Three integers: ( -1) (ffffffffffffff9d) (1777777777777777777635)] printf-1.14.3... Expected: [Three integers: (-99 ) (ffffffffffffff9d) (1777777777777777777635)] Got: [Three integers: (-1 ) (ffffffffffffff9d) (1777777777777777777635)] printf-1.14.4... Expected: [Three integers: ( -99) (ffffffffffffff9d) (1777777777777777777635)] Got: [Three integers: ( -1) (ffffffffffffff9d) (1777777777777777777635)] printf-1.14.5... Expected: [Three integers: (-00099) (ffffffffffffff9d) (1777777777777777777635)] Got: [Three integers: (-00001) (ffffffffffffff9d) (1777777777777777777635)] printf-1.14.6... Expected: [Three integers: ( -99) (ffffffffffffff9d) (1777777777777777777635)] Got: [Three integers: ( -1) (ffffffffffffff9d) (1777777777777777777635)] printf-1.15.1... Expected: [Three integers: -100 ffffffffffffff9c 1777777777777777777634] Got: [Three integers: -1 ffffffffffffff9c 1777777777777777777634] printf-1.15.2... Expected: [Three integers: ( -100) (ffffffffffffff9c) (1777777777777777777634)] Got: [Three integers: ( -1) (ffffffffffffff9c) (1777777777777777777634)] printf-1.15.3... Expected: [Three integers: (-100 ) (ffffffffffffff9c) (1777777777777777777634)] Got: [Three integers: (-1 ) (ffffffffffffff9c) (1777777777777777777634)] printf-1.15.4... Expected: [Three integers: ( -100) (ffffffffffffff9c) (1777777777777777777634)] Got: [Three integers: ( -1) (ffffffffffffff9c) (1777777777777777777634)] printf-1.15.5... Expected: [Three integers: (-00100) (ffffffffffffff9c) (1777777777777777777634)] Got: [Three integers: (-00001) (ffffffffffffff9c) (1777777777777777777634)] printf-1.15.6... Expected: [Three integers: ( -100) (ffffffffffffff9c) (1777777777777777777634)] Got: [Three integers: ( -1) (ffffffffffffff9c) (1777777777777777777634)] printf-1.16.1... Expected: [Three integers: -9999999 ffffffffff676981 1777777777777731664601] Got: [Three integers: -1 ffffffffff676981 1777777777777731664601] printf-1.16.2... Expected: [Three integers: (-9999999) (ffffffffff676981) (1777777777777731664601)] Got: [Three integers: ( -1) (ffffffffff676981) (1777777777777731664601)] printf-1.16.3... Expected: [Three integers: (-9999999) (ffffffffff676981) (1777777777777731664601)] Got: [Three integers: (-1 ) (ffffffffff676981) (1777777777777731664601)] printf-1.16.4... Expected: [Three integers: (-9999999) (ffffffffff676981) (1777777777777731664601)] Got: [Three integers: ( -1) (ffffffffff676981) (1777777777777731664601)] printf-1.16.5... Expected: [Three integers: (-9999999) (ffffffffff676981) (1777777777777731664601)] Got: [Three integers: (-00001) (ffffffffff676981) (1777777777777731664601)] printf-1.16.6... Expected: [Three integers: (-9999999) (ffffffffff676981) (1777777777777731664601)] Got: [Three integers: ( -1) (ffffffffff676981) (1777777777777731664601)] misuse-1.1... Error: invalid command name "sqlite_exec_printf" misuse-1.2... Error: invalid command name "sqlite_exec_printf" misuse-1.3... Error: invalid command name "sqlite_create_function" misuse-1.4... Error: invalid command name "sqlite_exec_printf" misuse-1.5... Error: invalid command name "sqlite_exec_printf" misuse-1.6... Ok misuse-2.1... Ok misuse-2.2... Error: invalid command name "sqlite_exec_printf" misuse-2.3... Expected: [1 {library routine called out of sequence}] Got: [1 {invalid command name "sqlite_create_function"}] misuse-2.4... Error: invalid command name "sqlite_exec_printf" misuse-2.5... Expected: [1 {library routine called out of sequence}] Got: [0 {1 2}] misuse-3.1... Ok misuse-3.2... Error: invalid command name "sqlite_exec_printf" misuse-3.3... Expected: [1 {library routine called out of sequence}] Got: [1 {invalid command name "sqlite_create_aggregate"}] misuse-3.4... Error: invalid command name "sqlite_exec_printf" misuse-3.5... Expected: [1 {library routine called out of sequence}] Got: [0 {1 2}] misuse-4.1... Ok misuse-4.2... Error: invalid command name "sqlite_exec_printf" misuse-4.3... Expected: [1 {library routine called out of sequence}] Got: [1 {invalid command name "sqlite_close"}] misuse-4.4... Error: invalid command name "sqlite_exec_printf" misuse-4.5... Expected: [1 {library routine called out of sequence}] Got: [0 {1 2}] misuse-5.1... Ok misuse-5.2... Error: invalid command name "sqlite_exec_printf" misuse-5.3... Error: invalid command name "sqlite_exec_printf" Skipping malloc tests: not compiled with -DMEMORY_DEBUG... 59 errors out of 22454 tests Failures on these tests: crash-1.2 crash-1.4 crash-1.5 printf-1.11.1 printf-1.11.2 printf-1.11.3 printf-1.11.4 printf-1.11.5 printf-1.11.6 printf-1.12.1 printf-1.12.2 printf-1.12.3 printf-1.12.4 printf-1.12.5 printf-1.12.6 printf-1.13.1 printf-1.13.2 printf-1.13.3 printf-1.13.4 printf-1.13.5 printf-1.13.6 printf-1.14.1 printf-1.14.2 printf-1.14.3 printf-1.14.4 printf-1.14.5 printf-1.14.6 printf-1.15.1 printf-1.15.2 printf-1.15.3 printf-1.15.4 printf-1.15.5 printf-1.15.6 printf-1.16.1 printf-1.16.2 printf-1.16.3 printf-1.16.4 printf-1.16.5 printf-1.16.6 printf-5.2 misuse-1.1 misuse-1.2 misuse-1.3 misuse-1.4 misuse-1.5 misuse-2.2 misuse-2.3 misuse-2.4 misuse-2.5 misuse-3.2 misuse-3.3 misuse-3.4 misuse-3.5 misuse-4.2 misuse-4.3 misuse-4.4 misuse-4.5 misuse-5.2 misuse-5.3 make: *** [fulltest] Error 1 [
#e8e8bd 748 new active 2004 May anonymous 2004 May 3 3 option to allow ignoring trailing whitespace in selects According to the SQL-92, when comparing strings using the = operator, the strings are supposed to be padded out with spaces to the same length. For example, a char(5) column contains 'abc ' (two spaces at the end) and you perform select * from table1 where field1 = 'abc' This should match that 'abc ' row. This is because both terms would have been padded with spaces to be matching lengths before comparison. SQLite should at least have the option to turn on SQL-92 compliant padding.
#e8e8bd 739 new active 2004 May anonymous Unknown 2004 May danielk1977 3 1 Suggestion speed query Suggestion If possible cache the result of query similar or identical. For example I have a table of 100000 record. I do a query with where clausal, this takes 2 seconds. Ok, next time I remake the same query, I spend self time. Is advantageous? No, my idea is to cache results until there are not changes or update. The cache has to be done with caution, invisible for user and without compromise the performance. For example of query result of 100 rows, I must wait another time the time needed to obtain the result. It is not fine! Piero Romani
#e8e8bd 737 new active 2004 May anonymous Shell 2004 May anonymous 3 3 xml export Export a sql statement to an oracle-style export xml. 30.0 30
... This can be done in shell.c following the xthml-table model except without the field escapes (in case we are putting xml in a column).Sqlite will not be able to say what xml a column should have without some kind of schema integration, which seems too complex.
#f2dcdc 721 code active 2004 May anonymous Shell 2004 May drh 3 2 empty .databases information in file shell.c around line 570 the callback_data structure needs to be added: data.cnt = 0; so the column widths are correctly used. or else, it will display empty lines. this problem is visible after executing one sql command
#e8e8bd 697 event active 2004 Apr anonymous Unknown 2004 May 3 4 Questionable locking _Situation:_ SELECT some data into a statement handle. Loop through that statement handle using fetchrow_hashref(). For each row, do something, and then UPDATE the database with the return code. My UPDATES were failing with little to no information coming back from the DBI layer. (Even w/ trace on.) _Solution:_ As it turns out, the DB was locked from the first SELECT, and the UPDATES couldn't be written. So, I used fetchall_hashref() instead. That way, I took all the info in, undefined the statement handle, and the UPDATES work fine. This may be as-intended, I can understand the appeal of simple locking for the niche SQLite fills. But, 1) the FAQ item 7, sentence one leads me to believe that SELECTS don't lock, and 2) common sense tells me that SELECTS are read-only and shouldn't lock. I also wrote this up at perlmonks.org as the problem was found. http://www.perlmonks.org/index.pl?node_id=345931 Thanks for SQLite -- it's one of my favorite open source packages. Do one thing and do it well. Thank you. _2004-May-03 19:26:07 by anonymous:_ {linebreak} Well, it seems that SqlLite only allows for one query to be completely executed at a time. This includes SELECT. To test this, create a database *test* as follows, create table test_table(a); INSERT INTO test_table VALUES('test'); Then run the following program. Executing another query does not work, even using a seperate VM. Right now, SELECT blocks, which makes things more difficult... :( Even worse, the DELETE does not even return an error - just fails silently. #include #include int main() { sqlite *d1, *d2; const char *tail1, *tail2; const char **col_data1, **col_names1; const char **col_data2, **col_names2; sqlite_vm *v1, *v2; int i, j; int pN; char del_msg[255]; char *err; d1 = sqlite_open( "test", 0, &err ); if( err != 0 ) printf( "Open error: %s\n", err ); d2 = sqlite_open( "test", 0, &err ); if( err != 0 ) printf( "Open error: %s\n", err ); /* Select one row */ printf( " allocated: %d %d\n", (int)d1, (int)d2 ); i = sqlite_compile( d1, "select * from test_table", &tail1, &v1, &err ); sqlite_step( v1, &pN, &col_data1, &col_names1 ); if( err != 0 ) printf( "Select error: %s\n", err ); printf( "nCols: %d\n", pN ); sprintf( del_msg, "delete from test_table where a=\"%s\"", col_data1[0]); printf( "%s\n", del_msg ); /* // UNCOMMENT FOR THIS TO WORK * * sqlite_finalize( v1, &err ); * if( err != 0 ) printf( "Finalize error: %s\n", err ); * */ /* Delete that row */ j = sqlite_compile( d2, del_msg, &tail2, &v2, &err ); if( err != 0 ) printf( "Delete error: %s\n", err ); sqlite_step( v2, &pN, &col_data2, &col_names2 ); sqlite_finalize( v2, &err ); if( err != 0 ) printf( "Finalize error: %s\n", err ); /* COMMENT FOR THIS TO WORK */ sqlite_finalize( v1, &err ); if( err != 0 ) printf( "Finalize error: %s\n", err ); /****************************/ sqlite_close( d1 ); sqlite_close( d2 ); return 0; }
#e8e8bd 714 new active 2004 Apr anonymous Unknown 2004 Apr drh 3 3 Change sqlite_decode_binary to return buffer size It would be nice to be able to have sqlite_decode_binary return the required buffer size, like the encode routine does. The reason is that in managed systems (we're using this in .NET) it avoids a needless allocation and then a copy. For example, without it, we need to allocate a buffer as big as the incoming one, decode, allocate one of the proper size, then copy the bytes. Otherwise, the array we return is incorrectly sized. I've made the following change... // TODO: Mark this up... was... out[i++] = c + e; if (out) out[i++] = c + e; else i++; By checking the out argument, we still get the increment count, but we don't write anywhere.
#e8e8bd 712 new active 2004 Apr anonymous Unknown 2004 Apr drh 3 3 Allow temporary databases to be created in specified folder Right now temporary databases are created in a default folder, for example the Temp folder under Windows. It should be possible to customize this location by passing the "context" of the current database to the temporary OS.C function. If that function received the current database, it could parse the folder and optionally create the temporary file in the same location.
#e8e8bd 711 new active 2004 Apr anonymous 2004 Apr drh 3 3 Provide a callback function to verify values before insert or update Such a function would be called during an insert or update with the column name, column type, and the value. The function could set an error and error message to deny the action. This would allow develops to create virtual datatypes with very little effort. For example, if a column was defined as type "Fruit", a function could check if the value was "Apple" and allow it, or "Cat" and deny it. _2004-Apr-28 23:00:07 by anonymous:_ {linebreak} use triggers
#e8e8bd 710 new active 2004 Apr anonymous Unknown 2004 Apr drh 3 4 Provide the ability to pass a user-data value during sqlite_compile It would be very useful to be able to pass a user-data value during the sqlite_compile command, that could then be retrieved in a user function. This would allow context-sensitive responses by the functions, by allowing them to know what "command" is executing them. I can provide further details if required.
#e8e8bd 707 new active 2004 Apr anonymous Unknown 2004 Apr drh 3 3 how to use internal functions? to name a few: 1: "SELECT @@CHECK_INTEGRITY", it will return the integrity of the database. 2: "SELECT @@DATABASE_VERSION", it will return the version of the database. 3: "SELECT @@ENGINE_VERSION", it will return the current version of the sqlite engine 4:"SELECT @@ENGINE_ENCODING", it will return the encoding of the sqlite engine. etc.
#f2dcdc 684 code active 2004 Apr anonymous Unknown 2004 Apr 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".
#f2dcdc 575 code active 2004 Jan anonymous VDBE 2004 Mar 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...
#f2dcdc 627 code active 2004 Feb anonymous 2004 Feb 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.
#e8e8bd 621 todo active 2004 Feb anonymous Unknown 2004 Feb anonymous 3 3 Assorted errors running test's on MAC OSX Mac OSX 10.3.2, gcc 3.3 {linebreak} sqlite 2.8.12 built from tarball{linebreak} Running tests gave following errors{linebreak} date-8.1...{linebreak} Expected: [{2003-10-26 12:34:00}]{linebreak} Got: [{2004-02-22 21:46:56}]{linebreak} date-8.2...{linebreak} Expected: [{2003-10-27 12:34:00}]{linebreak} Got: [{2004-02-23 21:46:56}]{linebreak} date-8.3...{linebreak} Expected: [{2003-10-28 12:34:00}]{linebreak} Got: [{2004-02-24 21:46:56}]{linebreak} date-8.4...{linebreak} Expected: [{2003-10-22 12:34:00}]{linebreak} Got: [{2004-02-25 21:46:56}]{linebreak} date-8.5...{linebreak} Expected: [{2003-10-01 00:00:00}]{linebreak} Got: [{2004-02-01 00:00:00}]{linebreak} date-8.6...{linebreak} Expected: [{2003-01-01 00:00:00}]{linebreak} Got: [{2004-01-01 00:00:00}]{linebreak} date-8.7...{linebreak} Expected: [{2003-10-22 00:00:00}]{linebreak} Got: [{2004-02-20 00:00:00}]{linebreak} date-8.8...{linebreak} Expected: [{2003-10-23 12:34:00}]{linebreak} Got: [{2004-02-21 21:46:56}]{linebreak} date-8.9...{linebreak} Expected: [{2003-10-23 12:34:00}]{linebreak} Got: [{2004-02-21 21:46:56}]{linebreak} date-8.10...{linebreak} Expected: [{2003-10-23 18:34:00}]{linebreak} Got: [{2004-02-22 03:46:56}]{linebreak} date-8.11...{linebreak} Expected: [{2003-10-21 12:34:00}]{linebreak} Got: [{2004-02-19 21:46:56}]{linebreak} *** Giving up...{linebreak} 11 errors out of 103 tests{linebreak} Failures on these tests: date-8.1 date-8.2 date-8.3 date-8.4 date-8.5 date-8.6 date-8.7 date-8.8 date-8.9 date-8.10 date-8.11{linebreak} format3-5.1...{linebreak} Expected: [3 121 3]{linebreak} Got: [3 121 0]{linebreak} format3-5.2...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} format3-5.3...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} format3-5.4...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} format3-5.5...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} format3-5.6...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} format3-5.7...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} format3-5.8...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} format3-5.9...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} format3-5.10...{linebreak} Expected: [3 121 3]{linebreak} Got: [3 121 0]{linebreak} format3-5.11...{linebreak} Expected: [3 100 3]{linebreak} Got: [3 100 0]{linebreak} *** Giving up...{linebreak} 11 errors out of 48 tests{linebreak} Failures on these tests: format3-5.1 format3-5.2 format3-5.3 format3-5.4 format3-5.5 format3-5.6 format3-5.7 format3-5.8 format3-5.9 format3-5.10 format3-5.11{linebreak} index-11.1...{linebreak} Expected: [0.10 3]{linebreak} Got: [0.10 0]{linebreak} index-11.2... Ok{linebreak} 1 errors out of 84 tests{linebreak} Failures on these tests: index-11.1{linebreak} intpkey-3.2... Ok{linebreak} intpkey-3.3...{linebreak} Expected: [5 hello world 2]{linebreak} Got: [5 hello world 0]{linebreak} intpkey-3.4...{linebreak} Expected: [5 hello world 3]{linebreak} Got: [5 hello world 0]{linebreak} intpkey-3.5... Ok{linebreak} intpkey-3.6...{linebreak} Expected: [5 hello world 3]{linebreak} Got: [5 hello world 0]{linebreak} intpkey-3.7...{linebreak} Expected: [5 hello world 11 hello world 5]{linebreak} Got: [5 hello world 11 hello world 0]{linebreak} intpkey-3.8...{linebreak} Expected: [11 hello world 5]{linebreak} Got: [11 hello world 0]{linebreak} intpkey-3.9...{linebreak} Expected: [11 hello world 1]{linebreak} Got: [11 hello world 0]{linebreak} intpkey-4.1... Ok{linebreak} intpkey-4.7...{linebreak} Expected: [11 hello world 1]{linebreak} Got: [11 hello world 0]{linebreak} intpkey-4.8...{linebreak} Expected: [11 hello world 1]{linebreak} Got: [11 hello world 0]{linebreak} intpkey-4.9...{linebreak} Expected: [11 hello world 1]{linebreak} Got: [11 hello world 0]{linebreak} intpkey-4.10...{linebreak} Expected: [-4 y z 1]{linebreak} Got: [-4 y z 0]{linebreak} intpkey-4.11...{linebreak} Expected: [-4 y z 1]{linebreak} Got: [-4 y z 0]{linebreak} *** Giving up...{linebreak} 11 errors out of 54 tests{linebreak} Failures on these tests: intpkey-3.3 intpkey-3.4 intpkey-3.6 intpkey-3.7 intpkey-3.8 intpkey-3.9 intpkey-4.7 intpkey-4.8 intpkey-4.9 intpkey-4.10 intpkey-4.11{linebreak} ioerr-1.1.3... Ok{linebreak} ioerr-2.1.1...{linebreak} Error: no such function: randstr{linebreak} ioerr-2.1.2... Ok{linebreak} testfixture: can't read "cksum": no such variable{linebreak} while executing{linebreak} "do_test ioerr-2.$n.3 {{linebreak} set r [catch {db eval {{linebreak} VACUUM;{linebreak} }} msg]{linebreak} # puts "error_pending=$::sqlite_io_error_pending"{linebreak} # if {$r} {puts..."{linebreak} ("for" body line 32){linebreak} invoked from within{linebreak} "for {set n 1} {$go} {incr n} {{linebreak} do_test ioerr-2.$n.1 {{linebreak} set ::sqlite_io_error_pending 0{linebreak} db close{linebreak} catch {file delete -force test.db}{linebreak} ca..."{linebreak} (file "../sqlite/test/ioerr.test" line 73){linebreak} memdb-1.1...{linebreak} Error: no such function: randstr{linebreak} memdb-1.2.1-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} memdb-1.2.2-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} memdb-1.2.9-0...{linebreak} Error: no such function: randstr{linebreak} memdb-1.3.1-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} memdb-1.3.2-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} memdb-1.3.9-0...{linebreak} Error: no such function: randstr{linebreak} memdb-1.4.1-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} memdb-1.4.2-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} memdb-1.4.9-0...{linebreak} Error: no such function: randstr{linebreak} memdb-1.5.1-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} *** Giving up...{linebreak} 11 errors out of 11 tests{linebreak} Failures on these tests: memdb-1.1 memdb-1.2.1-0 memdb-1.2.2-0 memdb-1.2.9-0 memdb-1.3.1-0 memdb-1.3.2-0 memdb-1.3.9-0 memdb-1.4.1-0 memdb-1.4.2-0 memdb-1.4.9-0 memdb-1.5.1-0{linebreak} minmax-1.1... Ok{linebreak} minmax-1.2...{linebreak} Expected: [19]{linebreak} Got: [0]{linebreak} minmax-1.3... Ok{linebreak} minmax-1.4...{linebreak} Expected: [19]{linebreak} Got: [0]{linebreak} minmax-1.5... Ok{linebreak} minmax-1.6...{linebreak} Expected: [1]{linebreak} Got: [0]{linebreak} minmax-1.7... Ok{linebreak} minmax-1.8...{linebreak} Expected: [1]{linebreak} Got: [0]{linebreak} minmax-1.9... Ok{linebreak} minmax-1.10...{linebreak} Expected: [19]{linebreak} Got: [0]{linebreak} minmax-2.0... Ok{linebreak} 5 errors out of 38 tests{linebreak} Failures on these tests: minmax-1.2 minmax-1.4 minmax-1.6 minmax-1.8 minmax-1.10{linebreak} rowid-4.5...{linebreak} Expected: [4 3]{linebreak} Got: [4 0]{linebreak} rowid-4.5.1...{linebreak} Expected: [3 3]{linebreak} Got: [3 0]{linebreak} rowid-4.6... Ok{linebreak} rowid-11.4... Ok{linebreak} 2 errors out of 123 tests{linebreak} Failures on these tests: rowid-4.5 rowid-4.5.1{linebreak} select2-3.2d...{linebreak} Expected: [3]{linebreak} Got: [0]{linebreak} select2-3.2e...{linebreak} Expected: [3]{linebreak} Got: [0]{linebreak} select2-3.3...{linebreak} Expected: [29999]{linebreak} Got: [0]{linebreak} select2-4.1... Ok{linebreak} 3 errors out of 19 tests{linebreak} Failures on these tests: select2-3.2d select2-3.2e select2-3.3{linebreak} trans-8.3... Ok{linebreak} trans-9.1...{linebreak} Error: no such function: randstr{linebreak} trans-9.2.1-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} trans-9.2.2-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} trans-9.2.9-0...{linebreak} Error: no such function: randstr{linebreak} trans-9.3.1-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} trans-9.3.2-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} trans-9.3.9-0...{linebreak} Error: no such function: randstr{linebreak} trans-9.4.1-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} trans-9.4.2-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} trans-9.4.9-0...{linebreak} Error: no such function: randstr{linebreak} trans-9.5.1-0...{linebreak} Error: cannot start a transaction within a transaction{linebreak} *** Giving up...{linebreak} 11 errors out of 130 tests{linebreak} Failures on these tests: trans-9.1 trans-9.2.1-0 trans-9.2.2-0 trans-9.2.9-0 trans-9.3.1-0 trans-9.3.2-0 trans-9.3.9-0 trans-9.4.1-0 trans-9.4.2-0 trans-9.4.9-0 trans-9.5.1-0{linebreak} vacuum-1.1...{linebreak} Error: no such function: randstr{linebreak} testfixture: can't read "cksum": no such variable{linebreak} while executing{linebreak} "do_test vacuum-1.2 {{linebreak} execsql {{linebreak} VACUUM;{linebreak} }{linebreak} cksum{linebreak} } $cksum"{linebreak} (file "../sqlite/test/vacuum.test" line 53){linebreak} where-1.0... Ok{linebreak} where-1.1...{linebreak} Expected: [3 121 3]{linebreak} Got: [3 121 0]{linebreak} where-1.2...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} where-1.3...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} where-1.4...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} where-1.5...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} where-1.6...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} where-1.7...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} where-1.8...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} where-1.9...{linebreak} Expected: [3 144 3]{linebreak} Got: [3 144 0]{linebreak} where-1.10...{linebreak} Expected: [3 121 3]{linebreak} Got: [3 121 0]{linebreak} where-1.11...{linebreak} Expected: [3 100 3]{linebreak} Got: [3 100 0]{linebreak} *** Giving up...{linebreak} 11 errors out of 12 tests{linebreak} Failures on these tests: where-1.1 where-1.2 where-1.3 where-1.4 where-1.5 where-1.6 where-1.7 where-1.8 where-1.9 where-1.10 where-1.11{linebreak} _2004-Feb-20 22:48:00 by anonymous:_ {linebreak} I looked up a previous bug I reported, and following the recommended solution , reran configure with --disable-shared. running 'make test' showed only one error remained format 3-11.3 expected [1] got [0]
#e8e8bd 613 doc active 2004 Feb anonymous 2004 Feb 3 4 Doc is wrong with some prototypes and const is missing for errmsg {link: http://www.hwaci.com/sw/sqlite/c_interface.html The C language interface to the SQLite library} is incorrect in some function-prototypes regardning constness. For example, it says " int sqlite_exec( _: sqlite *db,{linebreak} _: _char_ *sql,{linebreak} _: int (*xCallback)(void*,int,char**,char**),{linebreak} _: void *pArg,{linebreak} _: char **errmsg{linebreak} );"{linebreak} In this example, the parameter "char *sql" is "const char *sql" in my sqlite.h. In addition to this, the parameter char **errmsg should be const-ified in many functions (at the moment, they're still non-const). This is especially important to C++ developers.
#f2dcdc 608 code active 2004 Feb anonymous 2004 Feb 3 3 Problem with "pragma show_datatypes = on" and busy timeout When a busy timeout is set, pragma show_datatypes = on and SQLite sleeps some time on the lock, no datatypes are passed to the exec callback function. The attachment is an archive with a Makefile, a shell script and a program that reproduce the error. _2004-Feb-12 21:05:28 by anonymous:_ {linebreak} This problem breaks the auto-typing feature of PySQLite when a busy timeout is used.
#e8e8bd 93 new active 2002 Jul anonymous 2004 Jan 3 3 Can't open database when TEMP environment variable is not defined well This happened on WIN32 but is relevant to unix too. When the TEMP variable is not configured well the GetTempPath returns it without any checking that the directory exists. The error the database returns is something like "can't find table sqlite_temp_master" while the real error is that the temporary file couldn't be created. For security reason, the best practice is to give the application to set the temp directory. Then as the application writter I know where all the relevant sqlite files will be created and have full control of it. I will be happy to do the fix (If you find it suitable). Thanks in advanced Avner This happens always when using sqlite from a NT / Win2000 / XP service since they don't resolve the default TEMP directory var.
#e8e8bd 572 new active 2004 Jan anonymous Unknown 2004 Jan drh 3 3 sqlite 2.8.11 port to djgpp hello friends here is a patch to be applied to sqlite 2.8.11 to work with djgpp in a short file names environment. it's a very small piece of code patches, but i will explicitly stick to the sqlite copyright policy: The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights this code under copyright law. please apply this patch to the mainstream sources, for the benefit of all dos djgpp users. best regards, alex
#f2dcdc 369 code active 2003 Jun anonymous 2004 Jan 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.
#e8e8bd 445 build active 2003 Sep anonymous Unknown 2003 Dec anonymous 3 1 Compilation problem on MinGW dejan@KLEENE ~/src/sqlite$ make; head config.log; gcc -v ./libtool gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -I. -I./src -c ./src/os.c rm -f .libs/os.lo gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -I. -I./src -c ./src/os.c -DDLL_EXPORT -DPIC -o .libs/os.lo src/os.c: In function `sqliteOsReadLock': src/os.c:1142: storage size of `lock' isn't known src/os.c:1144: `F_RDLCK' undeclared (first use in this function) src/os.c:1144: (Each undeclared identifier is reported only once src/os.c:1144: for each function it appears in.) src/os.c:1147: `F_SETLK' undeclared (first use in this function) src/os.c: In function `sqliteOsWriteLock': src/os.c:1246: storage size of `lock' isn't known src/os.c:1248: `F_WRLCK' undeclared (first use in this function) src/os.c:1251: `F_SETLK' undeclared (first use in this function) src/os.c: In function `sqliteOsUnlock': src/os.c:1358: storage size of `lock' isn't known src/os.c:1360: `F_UNLCK' undeclared (first use in this function) src/os.c:1363: `F_SETLK' undeclared (first use in this function) make: *** [os.lo] Error 1 This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.57. Invocation command line was $ ./configure --enable-utf8 --prefix=/usr/local ## --------- ## ## Platform. ## Reading specs from C:/GNU/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-exceptions Thread model: win32 gcc version 3.2.3 (mingw special 20030504-1) See Ticket #433. e
#e8e8bd 409 event active 2003 Jul anonymous Unknown 2003 Dec anonymous 3 1 sqlite_open will cause segfault when using Rational PurifyPlus/Linux Note: I'm not certain if this is a sqlite or purifyplus problem While trying to troubleshoot some minor memory leaks in my application, I noticed that when using PurifyPlus the appliation will segfault when calling sqlite_open. I encountered the same problem when profiling src/threadtest.c. 1 - thread 11 - (thread) Run @ Sat Jul 19 23:58:54 2003 SIG (Signal 11 Handled: Segmentation fault) It occurs near after: worker_bee [/scratch/hsiab_c/hsiabd/t/sql/sqlite/src/threadtest.c] line 207 main [/scratch/hsiab_c/hsiabd/t/sql/sqlite/src/threadtest.c] line 265 Program exit code: 11 No Memory Leak detected The same problem happens when testing with an incredibly simple program: #include #include #include #ifdef MTRACE #include #endif int main() { sqlite *db; char *azErr; #ifdef MTRACE mtrace(); #endif db = sqlite_open("/tmp/testdb", 0, &azErr); if (db == 0) { printf("Couldn't open db file!\n"); free(azErr); exit(0); } sqlite_close(db); } Oddly enough, when I mtrace this program is complains with: Memory not freed: ----------------- Address Size Caller 0x08049bd0 0x40 at 0x4004a3ac I'm not sure if this is even related. Any ideas? This problem is occuring on Redhat 7.2 with sqlite 2.8.5 and purifyplus 2003.06.00.
#e8e8bd 404 new active 2003 Jul anonymous 2003 Dec 3 3 new C API: sqlite_get_table_with_types with type information Patches for a new C API function: sqlite_get_table_with_types, which is like sqlite_get_table but also adds type information in the return data which apepars right after the column names. Implementation (patch is against 2.8.3) is almost zero overhead and only needs an extra few lines: --- table.c.old Sun Jul 13 11:59:18 2003 +++ table.c Sun Jul 13 14:54:13 2003 @@ -33,6 +33,7 @@ int nColumn; int nData; int rc; + int headHasType; } TabResult; /* @@ -50,7 +51,7 @@ ** we need to remember from this invocation of the callback. */ if( p->nRow==0 && argv!=0 ){ - need = nCol*2; + need = nCol * (p->headHasType ? 3 : 2); }else{ need = nCol; } @@ -69,8 +70,9 @@ ** the names of all columns. */ if( p->nRow==0 ){ + int cols_top = (p->headHasType ? nCol * 2 : nCol); p->nColumn = nCol; - for(i=0; iflags |= SQLITE_CallBackNoAbort;{linebreak} _:}else{{linebreak} _::db->flags &= ~SQLITE_CallBackNoAbort;{linebreak} _:}{linebreak} }else{linebreak} In vbde.c: CHANGE line 5751: from{linebreak} if( rc ){ {linebreak}{linebreak} TO {linebreak}{linebreak} if( rc && ( !(db->flags & SQLITE_CallBackNoAbort) || rc != SQLITE_ABORT) ){{linebreak} I don't believe these changes will conflict with existing callback abort responses, however I am not completely familiar with all parts of sqlite, therefore I would like to hear the thoughts of DRH and the sqlite community.
#f2dcdc 330 code active 2003 May anonymous VDBE 2003 May 3 4 Aggregator's error are ignored Any error set by aggregator functions using sqlite_set_result_error() is ignored and returned as the aggregator's result. In vdbe.c, the AggNext and AggReset operators implementation do not check the context's isError attribute after the xFinalize function is called. Errors reported by normal functions works fine. Additional note on errors from aggregates: there is an requirement (and corresponding assert in the code) that sqlite_set_result_error will never be called from xStep callback. So it is required to wait for the first xFinalize call, this leads to allocation of extra memory to remember that an error is occured. Can it be allowed to call this function from xStep callback ?
#e8e8bd 279 new active 2003 Apr anonymous 2003 May 3 3 WinCE port of CVS version as of 02 Apr 2003 I've re-ported http://cvs.hwaci.com:2080/sqlite/tktview?tn=169 sqlite to Windows CE. Currently only supports MIPS CPU's and x86 but ading a CPU is a 2 liner. Code and diffs attached. The new files (contain _wince in the filename) in my build system are in a sub dir called WinCE_src and are in the include path before the sqlite src dir. The assert_wince.h is actually called assert.h. Same for config.h. The diffs look bigger than they really are as I've re-indented the original Windows code to match the new #IFDEF's. I've include os.h, os.c and tokenize.c for clarity. If you just want the src to build with evc, here is a complete zip ball http://www.geocities.com/clach04/src/sqlite/wince_sqlite_CVS_2003_04_02_src.zip Chris It should be considered that Windows CE doesn't support the FILE_FLAG_DELETE_ON_CLOSE option. This may cause a lot of problems with SQLite temporary files.
#e8e8bd 286 doc active 2003 Apr anonymous 2003 Apr 3 3 Tcl command documentation does not explain (minus) options. The -options of the sqlite tcl command are not documented. -version : returns versions of sqlite -encoding : returns default encoding -tcl-uses-utf : returns whether tcl can handle utf strings
#e8e8bd 278 doc active 2003 Apr anonymous Unknown 2003 Apr anonymous 3 3 Possible documentation bug in "expression" section. The documentation for expressions shows this: expr ::= ... ( select-statement ) | CASE [expr] ( WHEN expr THEN expr )+ [ELSE expr] END I _think_ this ought to be: expr ::= ... ( select-statement ) | SELECT CASE [expr] ( WHEN expr THEN expr )+ [ELSE expr] END The "SELECT CASE" form seems to be needed, at least in triggers (although, I don't recall if I tried simply "CASE ..." or not).
#e8e8bd 271 event active 2003 Mar anonymous Unknown 2003 Mar drh 3 2 'make test' fails on MacOS X As per a message from drh, adding -DSQLITE_TEST=1 to the make file may fix the problem. Unfortunately adding -DSQLITE_TEST=1 to the makefile broke the sqlite build (not test) with the linker errors below. Adding -DSQLITE_TEST=1 just for the 'make test' did not fix the problem with the tests. {linebreak} {linebreak}---- from 'make test' with or without -DSQLITE_TEST=1 {linebreak} trans-9.1... {linebreak} Error: no such function: randstr {linebreak} trans-9.2.1-0... {linebreak} Error: cannot start a transaction within a transaction {linebreak} trans-9.2.2-0... {linebreak} Error: cannot start a transaction within a transaction {linebreak} trans-9.2.9-0... {linebreak} Error: no such function: randstr {linebreak} trans-9.3.1-0... {linebreak} Error: cannot start a transaction within a transaction {linebreak} trans-9.3.2-0... {linebreak} Error: cannot start a transaction within a transaction {linebreak} trans-9.3.9-0... {linebreak} Error: no such function: randstr {linebreak} trans-9.4.1-0... {linebreak} Error: cannot start a transaction within a transaction {linebreak} trans-9.4.2-0... {linebreak} Error: cannot start a transaction within a transaction {linebreak} trans-9.4.9-0... {linebreak} Error: no such function: randstr {linebreak} trans-9.5.1-0... {linebreak} Error: cannot start a transaction within a transaction {linebreak} *** Giving up... {linebreak} 11 errors out of 13684 tests {linebreak} Failures on these tests: trans-9.1 trans-9.2.1-0 trans-9.2.2-0 {linebreak} trans-9.2.9-0 trans-9.3.1-0 trans-9.3.2-0 trans-9.3.9-0 trans-9.4.1-0 {linebreak} trans-9.4.2-0 trans-9.4.9-0 trans-9.5.1-0 {linebreak} make: *** [test] Error 1 {linebreak} {linebreak}---- from 'make': {linebreak} ld: multiple definitions of symbol _btree_native_byte_order {linebreak} auth.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} btree.lo definition of _btree_native_byte_order in section (__DATA,__data) {linebreak} build.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} delete.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} expr.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} func.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} hash.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} insert.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} main.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} os.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} pager.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} ld: multiple definitions of symbol _journal_format {linebreak} btree.lo definition of _journal_format in section (__DATA,__common) {linebreak} pager.lo definition of _journal_format in section (__DATA,__data) {linebreak} ld: multiple definitions of symbol _pager_refinfo_enable {linebreak} btree.lo definition of _pager_refinfo_enable in section (__DATA,__common) {linebreak} pager.lo definition of _pager_refinfo_enable in section (__DATA,__data) {linebreak} parse.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} printf.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} random.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} select.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} table.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} tokenize.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} update.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} util.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} vdbe.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} where.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} trigger.lo definition of _btree_native_byte_order in section (__DATA,__common) {linebreak} make: *** [libsqlite.la] Error 1 _2004-Aug-14 00:40:23 by anonymous:_ {linebreak} On Mac OSX 10.3.5 with sqlite 3.0.4, "make test" resulted in:{linebreak} _: 0 errors out of 22420 tests I suggest this bug be closed. ---- _2004-Nov-09 20:48:41 by anonymous:_ {linebreak} Server compiled fine here on Mac OS X 10.3.6, none of the tests fail.
#e8e8bd 236 new active 2003 Jan anonymous 2003 Feb 3 3 Add RENAME TABLE - will be easier to work around missing ALTER TABLE Currently the recommended method to ALTER TABLE is: 1: Create a temporary table. 2: Copy all data from original table to temporary table. 3: Drop the original table. 4: Create a new table. 5: Copy all data from the temporary table to the new table. This means that most of the data is copied twice - with a big database this may take quite some time. I suggest adding a RENAME TABLE command, which will cut 50% of the overhead (copy the data only once instead of twice): 1: Rename the original table to a temporary name. 2: Create a new table. 3: Copy data from the temporary/original table to the new table. 4: Drop the temporary/original table. A further enhancement would be to make the RENAME TABLE an internal command (not exposed to the SQL interface), and use it internally in order to implement an ALTER TABLE feature. This may not be the most efficient ALTER TABLE out there, but at least will make SQLite much more compatible with standard SQL commands. It will certainly make life easier during development, when tables need to be altered all the time. This suggestion isn't as easy to implement as it sounds. Because VIEWs, TRIGGERs, FOREIGN KEYs,... can reference a table by name, renaming a table means modifying their schemas to do the renaming, and handling all kinds of cases. One trick might be to have the parser modify the SQL used to create all SQLite TABLES, VIEWS,... by inserting special C-style comments into the SQL following every table name, which would allow you to find and replace them. For example: CREATE TABLE t1 (...); becomes CREATE TABLE t1 /*SQLITE-TABLE-NAME:t1*/ (...); Another way would be to create the temp table with a new name, and then have a SWAP TABLE pragma which ends up swapping the pointers to the tables. Afterwards you have to re-check constraints on both tables. Then you can drop the old table. Jim Lyon --- I agree that just renaming a table can have adverse side-effects as you describe. However, I suggest RENAME TABLE only as an intermediate solution for the missing ALTER TABLE. If used only in the way I suggest, then RENAME TABLE will not have any side effects, as it will just be part of a procedure that results in no change to the original table name: 1: Rename original table to temp name. 2: Create new table with ORIGINAL name. 3: Move data from previous to new table. 4: Drop previous table. As you can see in step 2, the "new" table retains the original name, so any references from other tables should be retained. I think that the SWAP TABLE you suggest is very similar. Of course, references to specific fields may be affected (if the new table structure drops some fields), but this is anyway the case with ALTER TABLE. Eyal Zvi.
#e8e8bd 164 event active 2002 Oct anonymous CodeGen 2002 Oct anonymous 3 4 Compiler warnings with MS Visual C++ 6.0 Hi, when I incorporated the "sqlite_source.zip" source code into a Microsoft Visual C++6.0 sample application, I got 24 warnings, mostly due to some signed/unsigned mismatch. It looks as it still works fine (no difference as when I used the DLL), but you never know if this holds true alltimes. Not showing up warnings would improve convidence into the product. Regards, Louis Schneider Deleting intermediate files and output files for project 'GENERIC - Win32 Release'. --------------------Configuration: GENERIC - Win32 Release-------------------- Compiling resources... Compiling... GENERIC.C where.c build.c delete.c expr.c C:\samples\techart\tech\win32\generic3\expr.c(1461) : warning C4018: '!=' : signed/unsigned mismatch func.c hash.c insert.c main.c opcodes.c os.c C:\samples\techart\tech\win32\generic3\os.c(495) : warning C4018: '==' : signed/unsigned mismatch pager.c C:\samples\techart\tech\win32\generic3\pager.c(346) : warning C4018: '>' : signed/unsigned mismatch C:\samples\techart\tech\win32\generic3\pager.c(1008) : warning C4018: '>=' : signed/unsigned mismatch parse.c printf.c random.c select.c C:\samples\techart\tech\win32\generic3\select.c(99) : warning C4018: '==' : signed/unsigned mismatch shell.c table.c tokenize.c trigger.c Generating Code... parse.c(6771) : warning C4761: integral size mismatch in argument; conversion supplied parse.c(6782) : warning C4761: integral size mismatch in argument; conversion supplied Compiling... update.c util.c vdbe.c C:\samples\techart\tech\win32\generic3\vdbe.c(2069) : warning C4244: 'initializing' : conversion from 'double ' to 'int ', possible loss of data btree.c C:\samples\techart\tech\win32\generic3\btree.c(2306) : warning C4018: '<' : signed/unsigned mismatch Generating Code... C:\samples\techart\tech\win32\generic3\btree.c(629) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(1762) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(1764) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(516) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(520) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(534) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(538) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(541) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(482) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(483) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(410) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(421) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(432) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(434) : warning C4761: integral size mismatch in argument; conversion supplied C:\samples\techart\tech\win32\generic3\btree.c(1924) : warning C4761: integral size mismatch in argument; conversion supplied Linking... Creating library GENERIC.lib and object GENERIC.exp GENERIC.exe - 0 error(s), 24 warning(s)
#e8e8bd 139 new active 2002 Aug anonymous Pager 2002 Aug 3 3 Named transactions are misleading as documented As documented it appears as though you can assign meaningful names to transactions, but in practice the names are just a throwaway for SQL92 compatibility. Nested transactions could be implemented if names were used -- perhaps by using markers in the journal file. This method would work well and provide for unlimited nesting of transactions given that sqlite does not support concurrent transactions. Example nested transaction: begin transaction t1; -- creates journal: mydb-journal ... inserts, updates, deletes, etc... ... begin transaction t1a; -- adds a marker (e.g. 'begin t1a') to the journal ... inserts, updates, deletes, etc... ... commit transaction t1a; -- adds a marker (e.g. 'commit t1a') to the journal ... begin transaction t1b; -- adds a marker (e.g. 'begin t1b') to the journal ... ... begin transaction t1b1; -- adds a marker (e.g. 'begin t1b1') to the journal ... commit transaction t1b1; ... rollback transaction t1b; -- rolls back the database to journal marker 'begin t1b' rollback transaction t1; -- rolls back to the beginning of the journal, undoing -- the commit performed in transaction t1a.
#f2dcdc 2905 code active 2008 Jan anonymous 2008 Jan 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 2903 code active 2008 Jan anonymous 2008 Jan 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 1
I'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.
#f2dcdc 2911 code active 2008 Jan anonymous 2008 Jan 2 2 Adding parentheses to a FROM clause Hi, Parentheses in a FROM statement seem to mess with the ability to use table aliases in the "what" part. Here is an example: Start SQLite: $ sqlite3 employee.db SQLite version 3.5.4 Enter ".help" for instructions create a couple of tables and populate them with test data: sqlite> create table person (id integer, name text, employerid integer); sqlite> create table employer (id integer, name text); sqlite> insert into person (id, name, employerid) values (1, "Dave", 1); sqlite> insert into employer (id, name) values (1, "ACME"); Run a simple query with *no parentheses* in the FROM statement: sqlite> select b.id from person as a inner join employer as b on a.employerid = b.id; 1 Everything works as expected. Now, repeat that query *with parentheses*: sqlite> select b.id from (person as a inner join employer as b on a.employerid = b.id); SQL error: no such column: b.id There you have it. This may be related to ticket #1822, although that ticket deals with aliases and subqueries. This problem seems to be more fundamental. Many thanks, -- Dave
#e8e8bd 2853 new active 2007 Dec anonymous 2008 Jan 2 3 optimizer fails to use an index on MAX subquery i have these 2 identical queries with an index on (place_id,visit_date), the second query is about 2x fast the the first, while i'd expect that the MAX is faster than a limited order by clause... It's like the index is mis-used with MAX SELECT h.id, h.url, h.title, h.rev_host, h.visit_count, (SELECT MAX(visit_date) FROM moz_historyvisits WHERE place_id = h.id AND visit_type NOT IN(0,4)), f.url, null, null FROM moz_places h LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id WHERE h.id IN (SELECT DISTINCT p.id FROM moz_places p JOIN moz_historyvisits ON place_id = p.id WHERE hidden <> 1 AND visit_type NOT IN (0,4) ORDER BY visit_date DESC LIMIT 10) ORDER BY 6 DESC; SELECT h.id, h.url, h.title, h.rev_host, h.visit_count, (SELECT visit_date FROM moz_historyvisits WHERE place_id = h.id AND visit_type NOT IN(0,4) ORDER BY visit_date DESC LIMIT 1), f.url, null, null FROM moz_places h LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id WHERE h.id IN (SELECT DISTINCT p.id FROM moz_places p JOIN moz_historyvisits ON place_id = p.id WHERE hidden <> 1 AND visit_type NOT IN (0,4) ORDER BY visit_date DESC LIMIT 10) ORDER BY 6 DESC; _2007-Dec-20 04:13:44 by anonymous:_ {linebreak} Can you supply the schema of these tables and all related indexes? ---- _2007-Dec-20 10:55:29 by danielk1977:_ {linebreak} Correct. SQLite does not use the index to optimize the max() in the first query. But it does use it to optimize ORDER BY in the second. ---- _2007-Dec-21 00:54:10 by anonymous:_ {linebreak} the schema is that of mozilla firefox 3 places.sqlite, with an added index on moz_historyvisits(place_id,visit_date), this is extracted from a i bug i was working on. Do you need that i append the full schema here? Will this be fixed to use the index with max or is that the expected behaviour? ---- _2007-Dec-21 15:59:58 by drh:_ {linebreak} We will be enhancing the min()/max() optimization to be able to cover the case you describe above. But this will take some time to get right. If you are in a hurry, it seems like modifying your SQL is the easiest way to go. The current optimizer recognizes queries of the form: SELECT min(x) FROM table; SELECT max(x) FROM table; And it causes special VDBE code to be generated for these cases. The presence of a WHERE clause defeats the current optimization. We need to modify the optimizer to recognize queries of the form: SELECT min(x) FROM table WHERE expr And convert them into: SELECT x FROM table WHERE expr AND x NOT NULL ORDER BY x LIMIT 1 But we only want to do this optimization if the ORDER BY can be evaluated using an index. If we have to accumulate the entire result set, sort it, then take the largest entry, that is more work than just keeping track of the largest entry as we loop through the result set. Notice the addition of the "x NOT NULL" term in the WHERE clause. This is critical to preserving correct semantics. The query optimizer currently does not know how to deal with a NOT NULL. It just evaluates all rows, tests them individually for NULL, and throws out those that match. This would work in most cases, but would slow down in a min() where there were many NULL entries. The current implemention of the min() optimization knows to skip over the NULL entries in a single operation. The WHERE generator part of the optimizer will need to be enhanced to recognize NOT NULL constraints and skip over them. All of this is a substantial change. The min()/max() optimization function will be rewritten from scratch. Significant and non-trivial modifications will need to be made to the code that looks for indices and generates the WHERE clause constraints. There are many opportunities to make coding mistakes, so we will need to spend a lot of time in testing before we put these changes into production. So, we will be working the problem. But do not expect an overnight fix. I suppose that while we are redesigning the min/max optimizer, we might as well also fix it so that SELECT arbitrary_expr(max(x)) FROM table WHERE expr; gets converted into SELECT arbitrary_expr(x) FROM table WHERE expr AND x NOT NULL ORDER BY x DESC LIMIT 1; ---- _2007-Dec-31 06:41:03 by anonymous:_ {linebreak} Regarding: SELECT min(x) from table WHERE expr being converted to: SELECT x FROM table WHERE expr AND x NOT NULL ORDER BY x LIMIT 1 There's no need for the "x NOT NULL" condition considering NULL is returned by min() (or max for that matter) when no rows match. sqlite> .nullvalue sqlite> select min(a) from (select 123 as a) where a=7; sqlite> select min(a) from (select NULL as a) where a=7; Even with this in mind, you can see that the rewritten query still does not return the same result in this case: sqlite> select a from (select 123 as a) where a=7 order by 1 limit 1; -- no rows returned Logic would have to be added to return a NULL row in the event the WHERE clause matches no rows. ---- _2007-Dec-31 07:06:22 by anonymous:_ {linebreak} Given: SELECT min(x) from table WHERE expr If column *x* or the *WHERE expr* can make use of an index, then the min query should be converted to: SELECT x from ( SELECT x FROM table WHERE expr ORDER BY x LIMIT 1 ) UNION ALL SELECT NULL LIMIT 1 which ought to cover all the corner cases, even if the WHERE matches no rows. ---- _2008-Jan-01 19:21:51 by anonymous:_ {linebreak} This ticket is related to WHERE cost estimation in ticket #2857. Given: create table stuff(a,b,c,d); insert into stuff values(1,2,3,4); create temp view v1 as select random()%100, random()%100, random()%1000, random()%10000 from stuff x, stuff y; insert into stuff select * from v1; insert into stuff select * from v1; insert into stuff select * from v1; insert into stuff select * from v1; insert into stuff select * from v1; create index stuff_b on stuff(b); create index stuff_c on stuff(c); create index stuff_d on stuff(d); analyze; In the following example the existing min() implementation which uses a full table scan: sqlite> explain query plan select min(c) from stuff where a=12345; 0|0|TABLE stuff sqlite> select min(c) from stuff where a=12345; (null) CPU Time: user 1.388087 sys 0.216014 is faster than performing the select min->order by/limit transform which uses an index: sqlite> explain query plan select c from stuff where a=12345 order by 1 limit 1; 0|0|TABLE stuff WITH INDEX stuff_c ORDER BY sqlite> explain query plan select c from (select c from stuff where a=12345 order by c limit 1) union all select null limit 1; 0|0|TABLE stuff WITH INDEX stuff_c ORDER BY 0|0|TABLE AS sqlite_subquery_82F83F8_ CPU Time: user 0.000000 sys 0.000000 sqlite> select c from (select c from stuff where a=12345 order by c limit 1) union all select null limit 1; (null) CPU Time: user 15.880993 sys 15.400962 Note that a=12345 is always false in this data set. Had a=23 been used instead, we can see that the transformed select would be much faster than the original min() select: sqlite> select min(c) from stuff where a=23; -999 CPU Time: user 1.552097 sys 0.148009 sqlite> select c from (select c from stuff where a=23 order by c limit 1) union all select null limit 1; -999 CPU Time: user 0.004001 sys 0.000000 I don't think WHERE clause cost estimation can be done accurately without using a statistical method based on historical WHERE clause hit percentages. ---- _2008-Jan-05 18:15:39 by anonymous:_ {linebreak} I appreciate that you have more refinements pending, but this query in particular has regressed from sqlite 3.5.4 using the schema mentioned above: -- sqlite 3.5.4 sqlite> select min(c) from stuff where a=12345; (null) CPU Time: user 1.532095 sys 0.132008 -- as of Check-in [4687] sqlite> select min(c) from stuff where a=12345; (null) CPU Time: user 23.041440 sys 16.369023
#f2dcdc 2867 code active 2008 Jan anonymous 2008 Jan 2 2 doesn't build on Cygwin - wrong sqlite3 exe suffix The new Makefile used $(EXE), which doesn't seem to be defined (typo?) _2008-Jan-02 11:12:39 by anonymous:_ {linebreak} Same on mingw: Following patch fixes things: --- sqlite-3.5.4/Makefile.in Thu Dec 13 19:17:42 2007 +++ sqlite-3.5.4-mingw-fix/Makefile.in Wed Jan 2 11:37:50 2008 @@ -322,7 +322,7 @@ -o $@ $(TOP)/src/shell.c libsqlite3.la \ $(LIBREADLINE) $(TLIBS) -sqlite3$(EXE): $(TOP)/src/shell.c sqlite3.c sqlite3.h +sqlite3$(TEXE): $(TOP)/src/shell.c sqlite3.c sqlite3.h $(LTLINK) $(READLINE_FLAGS) -o $@ \ -DSQLITE_MAX_SQL_LENGTH=1000000000 \ -USQLITE_THREADSAFE -DSQLITE_THREADSAFE=0 \ @@ -577,7 +577,7 @@ -e 's,$$,\\n",' \ $(TOP)/tool/spaceanal.tcl >spaceanal_tcl.h $(LTLINK) -DTCLSH=2 -DSQLITE_TEST=1 $(TEMP_STORE)\ - -o sqlite3_analyzer$(EXE) $(TESTSRC) $(TOP)/src/tclsqlite.c \ + -o sqlite3_analyzer$(TEXE) $(TESTSRC) $(TOP)/src/tclsqlite.c \ libtclsqlite3.la $(LIBTCL)
#f2dcdc 2863 code active 2007 Dec anonymous 2007 Dec 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
#f2dcdc 2857 code active 2007 Dec anonymous 2007 Dec 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.
#f2dcdc 2721 code active 2007 Oct anonymous 2007 Dec 2 1 if db file is in a folder with non-ansi character some functions fail If database file is located in directory with some non-ANSI characters (in my case with a Russian subdirectory c:\Мои документы\Data_Jobs), or it's name is non-ansi. Some functions fail to execute sql. For example (with defined UNICODE): TCHAR sql[512]; _stprintf(sql, _T("INSERT INTO tab_SurveyedPoints (name, comment, code,") _T("coordinatetype, b, l, h, solutiontype, sigmah, sigmav)") _T(" VALUES ('%s','%s','%s',0,%lf,%lf,%lf,0,%lf,%lf);"), point.m_name.c_str(), point.m_description.c_str(), point.m_code.c_str(), point.m_coordinates.b, point.m_coordinates.l, point.m_coordinates.h, point.m_sigmah, point.m_sigmav); int rc1 = sqlite3_prepare16(m_db, sqlfmt, -1, &stmt, (const void**)&pszTail); rc != SQLITE_OK
But if I move the file to c:\My documents\Data_Jobs this works ok. It's improbable behaviour, but I can't work around yet. Although, prepare() functions work ok as well in both cases. Yuri Noyanov. _2007-Oct-11 19:33:34 by drh:_ {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.
#e8e8bd 285 build active 2003 Apr anonymous Unknown 2007 Nov 2 2 Configure doesn't honour LDFLAGS during build Right now the configure script in the 2.8.0 tar.gz and CVS can't quite build a working SQLite when Fink is installed - it gets confused with finding readline. (I've not been able to find the right places to add these changes). * if LDFLAGS is set it is used during the check phase of configure but it isn't used during the build, ie. LDFLAGS doesn't get into the Makefile, this leads to the readline support being turned on but the libraries not being available at link time * paths searched for readline.h should include /sw
#e8e8bd 2736 build active 2007 Oct anonymous 2007 Oct 2 2 build problems on freebsd on freebsd: --disable-threads does not work. it is accepted as a valid option but no defs are added to the makefile -lgcc needs to be included in SHLIB_LD_LIBS pkgIndex.tcl is not built when -DSQLITE_THREADSAFE=0 is added manually, this causes the install target to fail. _2007-Oct-17 21:16:23 by anonymous:_ {linebreak} I forgot to mention this is with the TEA version
#f2dcdc 2671 code active 2007 Sep shess 2007 Sep shess 2 4 Fts field-based queries are not correctly case-insensitive. CREATE VIRTUAL TABLE t USING fts2(A, B); -- At the SQL level, things are case-insensitive: INSERT INTO t (A, b) VALUES ('Test', 'Columns'); INSERT INTO T (a, B) VALUES ('Second', 'Test'); -- Unfortunately, fts cannot do field-level queries: SELECT rowid FROM t WHERE t MATCH 'test'; -- works SELECT rowid FROM t WHERE b MATCH 'test'; -- works SELECT rowid FROM t WHERE t MATCH 'b:test'; -- no results SELECT rowid FROM t WHERE t MATCH 'B:test'; -- no results It doesn't work because fts is keeping the column name as 'B', but the query parsing uses the results from the tokenizer, which are case-folded, and 'b' != 'B'. I'm thinking on the solution. A quick fix would be to make the azColumn storage be lowercase, but the core problem is that field names probably shouldn't be run through the tokenizer in the first place.
#f2dcdc 2294 code active 2007 Apr anonymous 2007 Sep 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.
#f2dcdc 2539 code active 2007 Jul anonymous 2007 Sep 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
#e8e8bd 2607 event active 2007 Aug anonymous 2007 Sep 2 1 Data loss, continuation to Re: [sqlite] how to flush database to disk? See that mailing list. The originator message : ======================== I've just lost a couple of days' worth of data when my app crashed. (Well, the data wasn't a total loss thanks to backup plans, but the database itself essentially reverted to its state of 2 days ago.) This is despite my app doing a COMMIT after every modification of the DB. It's acting as though all the changes were held in memory, or somehow journaled, and when the crash happened, the changes were all lost or rolled back. What I need is a way to force the database to save its data to disk while my app is running, so that in the event of a crash, I lose little or no data. How can I do this? I presume that closing the database would do the trick, but is there a less heavy-handed way? =========== The exact like that data loss occured at me too. Three times, non-repropucible regualrilly. What common in these losses ? {Editing+committing} in the main thread then {navigating, bof/eof checking, reading data} from within different threads then return to the main thread for {editing+committing}. _2007-Aug-31 19:38:26 by drh:_ {linebreak} The COMMIT does not actually occur until you call sqlite3_reset() and/or sqlite3_finalize() on all your prepared statements. Any prepared statement that has not been reset or finalized is still running, is incomplete, and is thus still holding the transaction open. I'm guessing that you have an unreset and unfinialized statement in your application. I wonder what would happen if we changed the definition of COMMIT so that it returned an error if there were active prepared statements. This is, technically, an incompatibility. But we are coming up on a release with several other minor incompatibilities, so now might be a good time to insert such a change. ---- _2007-Aug-31 19:45:36 by drh:_ {linebreak} I looked in the code, and it turns out we already do this. Perhaps the application is not checking the return code from the COMMIT to see that it is failing? ---- _2007-Aug-31 20:40:47 by anonymous:_ {linebreak} No error reports came from COMMIT. The data loss were noticed after UPDATE & COMMIT after massive reading of results of SQL addressing the same virtual (ATTACHed) tables, from within another thread. ---- _2007-Aug-31 20:53:48 by anonymous:_ {linebreak} Is it possible that a pending transaction survive app shutdown & then OS restart ? Is yes, then any DB error would cause rollback to the data on last BEGIN, isn't ? ---- _2007-Aug-31 21:00:18 by anonymous:_ {linebreak} But me committed each smallest change to dat,a then saw these refreshed data in the tables. And on the next day these data were present. Only reading (with full scrolling ) the affected virtual tables from within another thread then new editing then committing caused the loss. ---- _2007-Sep-01 23:12:31 by anonymous:_ {linebreak} You mention virtual tables. Their data is not maintained by the SQLite engine, but by your own module. If that doesn't implement ACID, you're out of luck. By definition:{linebreak} {quote: A virtual table is an interface to an external storage or computation engine that appears to be a table but does not actually store information in the database file.} references:{linebreak}{link: http://www.sqlite.org/lang_createvtab.html CreateVirtualTable}{linebreak} {wiki: VirtualTables VirtualTables} ---- _2007-Sep-04 04:51:15 by anonymous:_ {linebreak} Me was wrong. These were't true virtual tables. Me used a LEFT OUTER query to several tables residing in different ATTACHed databases. ---- _2007-Sep-04 04:52:01 by anonymous:_ {linebreak} were't => were not, above.
#e8e8bd 2566 build active 2007 Aug anonymous 2007 Aug 2 1 fts2 broken after vacuum Hi there, I'm testing your database and I'm having problems with fts2: --------- sqlite> select * from distB where distB match "MARIANO"; Assertion failed: *pData!='\0', file fts2amal.c, line 16790 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --------- Steps: 1) Create a new .db 2) Import data in new distA table 3) Import data in new distB table 4) Create a new distC virtual table (dts2) 5) insert into distC (rowid, f1, f2, f3) select rowid, f1, f2, f3 from DistB Everything working like a charm until here!!! The fts2 works very well, but after 6) vacuum; the fts seems broken... doing a select throws the error I paste at the post of the topic If you want the .db file I can send it to you (607MB) Thanks.-
#f2dcdc 2558 code active 2007 Aug anonymous 2007 Aug 2 3 Multiple JOIN USING() gives incorrect results I'm having a problem joining multiple tables with USING. It appears to work, but the results are incorrect. Here is an example to illustrate the problem. I believe the three SELECT statements should be equivalent, but they produce three different results. .header on .mode column CREATE TABLE Main (pk INTEGER PRIMARY KEY, name VARCHAR); CREATE TABLE OptA (pk INTEGER PRIMARY KEY, alpha VARCHAR); CREATE TABLE OptB (pk INTEGER PRIMARY KEY, beta VARCHAR); INSERT INTO Main VALUES (1, 'One'); INSERT INTO Main VALUES (2, 'Two'); INSERT INTO Main VALUES (3, 'Three'); INSERT INTO Main VALUES (4, 'Four'); INSERT INTO OptA VALUES (1, 'Alpha1'); INSERT INTO OptA VALUES (4, 'Alpha4'); INSERT INTO OptB VALUES (2, 'Beta2'); INSERT INTO OptB VALUES (4, 'Beta4'); SELECT * FROM Main LEFT JOIN OptA USING (pk) LEFT JOIN OptB USING (pk); SELECT * FROM Main LEFT JOIN OptB USING (pk) LEFT JOIN OptA USING (pk); SELECT Main.pk, name, alpha, beta FROM Main LEFT JOIN OptA ON Main.pk = OptA.pk LEFT JOIN OptB ON Main.pk = OptB.pk; Joining Main, OptA, and OptB omits Beta2: pk name alpha beta ---------- ---------- ---------- ---------- 1 One Alpha1 2 Two 3 Three 4 Four Alpha4 Beta4 Joining Main, OptB, and OptA omits Alpha1: pk name beta alpha ---------- ---------- ---------- ---------- 1 One 2 Two Beta2 3 Three 4 Four Beta4 Alpha4 Only by using ON instead of USING do we get the correct results: pk name alpha beta ---------- ---------- ---------- ---------- 1 One Alpha1 2 Two Beta2 3 Three 4 Four Alpha4 Beta4 I think this is basically the same issue as ticket #1637, but it's a more serious example. In that one, the query simply failed to compile. In this case, it seems to work, but gives you the wrong results. I've also tried this script in PostgreSQL 8.0.13. All three queries give (the same) correct results. _2007-Aug-08 17:34:27 by anonymous:_ {linebreak} The problem is that SQLite is transforming SELECT * FROM Main LEFT JOIN OptA USING (pk) LEFT JOIN OptB USING (pk); into SELECT Main.pk, name, alpha, beta FROM Main LEFT JOIN OptA ON Main.pk = OptA.pk LEFT JOIN OptB ON OptA.pk = OptB.pk; Here is a workaround to this bug that makes use of a subquery: select * from (SELECT * FROM Main LEFT JOIN OptA USING (pk)) LEFT JOIN OptB USING (pk); Conceivably all LEFT JOIN chains could be transformed into the above form, but that would decrease performance due to the intermediate result set of the subquery. Having it work without the subquery is tricky since sqlite must deduce that the last USING (pk) is equivalent to the first pk in the chain of joined tables, namely Main.pk, and not OptA.pk. Joe Wilson
#f2dcdc 2530 code active 2007 Jul anonymous 2007 Jul 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 2440 code active 2007 Jun rse 2007 Jun 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
#f2dcdc 2408 code active 2007 Jun anonymous 2007 Jun 2 1 BLOBs not output correctly in .mode insert (shell.c - isnumber) The method {linebreak} static int isNumber(const char *z, int *realnum) {linebreak} {linebreak} from shell.c is wrong. {linebreak} Steps to reproduce: {linebreak} 1. Get the file www.smatei.3x.ro/project1.zip {linebreak} 2. extract project1.db from the zip file {linebreak} 3. execute {linebreak} sqlite3 project1.db {linebreak} sqlite>.mode insert {linebreak} sqlite> select ID, Name, Color, Active, Priority, PrioritySource, IndexOrder, Language, 0 from Keywords; {linebreak} INSERT INTO Keywords VALUES(42,#####,0,1,0,0,42,'',0); {linebreak} INSERT INTO Keywords VALUES(41,'######',0,1,0,0,43,'',0);{linebreak} If you look at the 42 item, the string next to 42 is not enclosed by the string delimiter '. {linebreak} This is because the method isnumber returns that the string is number. It is not a number, it is a string in Hebrew (I inserted ### instead of the real strings). {linebreak} A fix for this might be to set the first parameter unsigned char {linebreak} static int isNumber(unsigned const char *z, int *realnum) {linebreak} but I am not sure, because I haven't written C code for a long time. {linebreak} If you have any more questions, please ask. {linebreak} Best Regards, {linebreak} Stefan _2007-Jun-11 14:46:03 by drh:_ {linebreak} Please show me what you get from the following query: SELECT ID, quote(cast(Name AS BLOB)) FROM Keywords WHERE ID IN (41,42); I need this information in order to track down the problem. ---- _2007-Jun-11 14:50:33 by anonymous:_ {linebreak} The output is 41|X'D791D7A8D799D799D7A7D793D790D7A0D7A1'{linebreak} 42|X'D7A1D798D7A4D7A1' ---- _2007-Jun-11 16:29:46 by drh:_ {linebreak} When I do this: CREATE TABLE t1(x); INSERT INTO t1 VALUES(cast(X'D791D7A8D799D799D7A7D793D790D7A0D7A1' as text)); INSERT INTO t1 VALUES(cast(X'D7A1D798D7A4D7A1' AS text)); .mode insert xyz SELECT * FROM t1; I see the Hebrew characters, properly quoted. Can you suggest another way to reproduce the problem? ---- _2007-Jun-11 16:34:55 by anonymous:_ SQLite version 3.3.17 Enter ".help" for instructions sqlite> create table t1(b blob); sqlite> insert into t1 values(X'0102030405060708090a0dABCD'); sqlite> .dump BEGIN TRANSACTION; CREATE TABLE t1(b blob); INSERT INTO "t1" VALUES(X'0102030405060708090A0DABCD'); COMMIT; sqlite> .mode insert sqlite> select * from t1; INSERT INTO table VALUES(' «Í'); sqlite> ---- _2007-Jun-11 20:07:09 by anonymous:_ {linebreak} If I recall correctly, sqlite3.exe assumes all I/O to and from the console is UTF-8. Windows consoles are either MBCS or UNICODE depending on the build settings. Sqlite3.exe was not compiled as UNICODE so anything inserted into a sqlite3 database will be inserted as MBCS. So if you insert into a database using a 3rd party application that does proper UTF-8, and then query it from the command-line, it will look wrong. Likewise, anything you insert from the command-line will look wrong when queried from an application that uses UTF-8. ---- _2007-Jun-11 20:42:18 by anonymous:_ {linebreak} .mode insert treats BLOBs as strings, which is a problem since it stops outputting at the first nil character. CREATE TABLE t1(a blob); INSERT INTO t1 VALUES(X'00000008090A0D0D0A00'); .mode insert whatever select * from t1; ---- _2007-Jun-12 07:39:12 by anonymous:_ {linebreak} Hi, My problem is not the way the string is displayed in the console. The application that reads the database reads it correctly. The problem is when I try to dump a certain table in a file using the following sequence: .output "file.txt"{linebreak} .mode insert whatever{linebreak} select f1, f2, f3 from t1;{linebreak} The result is a file that some Hebrew strings are not enclosed in ' (apostrophe). After debugging the code, I saw that the method isnumber does not return 0 for that string. It considers all the characters digits. This problem occurs only on Windows. We tried this on Mac and Linux, and it worked fine. Best Regards,{linebreak} Stefan{linebreak}
#f2dcdc 2398 code active 2007 Jun anonymous 2007 Jun 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_SYSCALLS
by leaving SQLITE3_RETRY_EINTR_SYSCALLS undefined, this should not affect the current code behaviour and should address the issues ticket author says and he can compile with those 'paranoic' checks. []'s ---- _2007-Jun-05 22:25:06 by anonymous:_ {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.
#e8e8bd 2397 build active 2007 Jun anonymous 2007 Jun 2 4 make install failed on Cygwin On WinXP Cygwin platform, `make install' failed. There are at least two problems. I could not resolve them. (1) Makefile defect. (2) Tcl on Cygwin is not compatible with other platforms. (1) can be fixed as follows: -install: sqlite3$ libsqlite3.la sqlite3.h ${HAVE_TCL:1=tcl_install} +install: sqlite3$(TEXE) libsqlite3.la sqlite3.h ${HAVE_TCL:1=tcl_install} (2) can not be fixed. There are at least two Tcl problems. (a) On Cygwin, an empty string can not be set to the environment variable. So tclinstaller.tcl line 9: set env(DESTDIR) "" this statement has no effect, and Tcl failed at line 10. (b) On Cygwin, [info sharedlibextension] returns ".dll". But `make all' generates static library only, libsqlite.dll does not exist. As a workaround, commenting out HAVE_TCL in Makefile did the trick.
#f2dcdc 2378 code active 2007 May anonymous 2007 May 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
#e8e8bd 1924 new active 2006 Aug anonymous Parser 2007 May 2 3 optimize queries on unions, constant folding Please see the attached patch that optimizes SELECTs on a compound subquery, or VIEWs containing UNIONS. pragma temp_store=memory; CREATE TABLE n1(a integer primary key); INSERT INTO "n1" VALUES(1); INSERT INTO "n1" VALUES(2); INSERT INTO "n1" VALUES(3); INSERT INTO "n1" VALUES(4); INSERT INTO "n1" VALUES(5); INSERT INTO "n1" VALUES(6); INSERT INTO "n1" VALUES(7); INSERT INTO "n1" VALUES(8); INSERT INTO "n1" VALUES(9); INSERT INTO "n1" VALUES(10); CREATE VIEW vu as select v3.a a, v5.a-v2.a*v7.a b from n1 v1,n1 v2,n1 v3,n1 v4,n1 v5,n1 v6,n1 v7; CREATE VIEW v2 as select * from vu union all select 7, 8; select count(*), avg(b) from v2 where a<3; The above query takes 58 seconds in sqlite 3.3.7, using 136M of temp_store. With the patch, it takes just 12 seconds and uses 26M of temp_store. The patch also performs 32 bit integer constant folding: sqlite> explain select 1*2+3-4%5/2|128; 0|Goto|0|4| 1|Integer|131|0| 2|Callback|1|0| 3|Halt|0|0| 4|Goto|0|1| 5|Noop|0|0| _2006-Aug-17 13:03:31 by anonymous:_ {linebreak} TK_REM (the '%' operator) is not handled correctly in the patch. It should follow the logic of TK_SLASH and check 'right' against zero. + case TK_REM: { v = left % right; break; } ... + case TK_SLASH: { + if (right) { + v = left / right; + } else { + return; + } + break; + } ---- _2006-Aug-17 15:50:20 by anonymous:_ {linebreak} These 2 cases can overflow a 32 bit value. The calculation should be done in 64 bit int math, and if the result can fit into 32-bits, then fold it, otherwise return (similar to TK_SLASH). + case TK_PLUS: { v = left + right; break; } + case TK_STAR: { v = left * right; break; } Or just handle all cases in 64-bit math. ---- _2006-Aug-18 10:11:53 by anonymous:_ {linebreak} Wouldn't TK_MINUS also be able to overflow 32-bit, just in the opposite direction, so to speak ? Example: -2000000000 - 2000000000 ---- _2006-Aug-18 13:51:05 by anonymous:_ {linebreak} should you make + i64 left; + i64 right; + i64 v; instead of + int left; + int right; + int v; to avoid int32 overflows. ---- _2006-Aug-18 16:27:21 by anonymous:_ {linebreak} The attachment sqlite337-union-and-constants-opt-v2.diff.txt addresses all reported issues and passes "make test" without any regressions. ---- _2006-Aug-18 19:41:20 by anonymous:_ {linebreak} You're not assuming that "right" could be a i64 value in this last patch... ---- _2006-Aug-19 13:41:14 by anonymous:_ {linebreak} right is a 32 bit value. /* ** If the expression p codes a constant integer that is small enough ** to fit in a 32-bit integer, return 1 and put the value of the integer ** in *pValue. If the expression is not an integer or if it is too big ** to fit in a signed 32-bit integer, return 0 and leave *pValue unchanged. */ int sqlite3ExprIsInteger(Expr *p, int *pValue){ ---- _2007-May-16 20:09:38 by anonymous:_ {linebreak} Updated patch as of May 16, 2007 CVS: http://marc.info/?l=sqlite-users&m=117934558505665&w=2 http://marc.info/?l=sqlite-users&m=117934558505665&q=p3 ---- _2007-May-19 15:47:51 by anonymous:_ {linebreak} Some improvements, new comments and a new test case. http://www.mail-archive.com/sqlite-users%40sqlite.org/msg24859.html http://marc.info/?l=sqlite-users&m=117958960408282&q=p3
#f2dcdc 2371 code active 2007 May anonymous 2007 May 2 2 sqlite3_errcode() and sqlite3_errmsg() return unexpected results The manual says that sqlite3_step() directly returns explicit error code if the query has been prepared with the new API sqlite3_prepare_v2(). Subsequently, the functions sqlite3_errcode() and sqlite3_errmsg() should return the correct appropriate error values as well, which they don't - instead something not matching the error is returned. One has to call sqlite3_reset() to get the correct values which should be unnecessary. See the example output below : sqlite3_step: result rc = 19, errcode = 1, errmsg = SQL logic error or missing database sqlite3_reset: result rc = 19, errcode = 19, errmsg = PRIMARY KEY must be unique Code for this example: #include #include #include #include #include int main(int argc, char **argv) { sqlite3 *db; int rc, errcode; sqlite3_stmt *stmt; const char *pztail; char *query; const char *errmsg; rc = sqlite3_open("test.db", &db); rc = sqlite3_exec(db, "create table t (x integer not null primary key)", NULL, NULL, NULL); rc = sqlite3_exec(db, "insert into t values(1)", NULL, NULL, NULL); query = "insert into t values(?)"; rc = sqlite3_prepare_v2(db, query, strlen(query), &stmt, &pztail); if( rc!=SQLITE_OK ){ fprintf(stderr, "SQL error: %d\n", rc); exit(1); } rc = sqlite3_bind_int(stmt, 1, 1); if( rc!=SQLITE_OK ){ fprintf(stderr, "SQL error: %d\n", rc); exit(1); } rc = sqlite3_step(stmt); errcode = sqlite3_errcode(db); errmsg = sqlite3_errmsg(db); printf("sqlite3_step: result rc = %d, errcode = %d, errmsg = %s\n", rc, errcode, errmsg); rc = sqlite3_reset(stmt); errcode = sqlite3_errcode(db); errmsg = sqlite3_errmsg(db); printf("sqlite3_reset: result rc = %d, errcode = %d, errmsg = %s\n", rc, errcode, errmsg); }
#e8e8bd 2351 secure active 2007 May anonymous 2007 May 2 2 UTF-16 convertor accepts malformed UTF-8 sequence UTF encoding convertor accepts some invalid sequences of UTF-8. $ ./sqlite3 -version 3.3.17 $ cat test.sql select hex(a), hex(b), a == b from (select '' a, '<31>' b); pragma encoding = 'UTF-16'; select hex(a), hex(b), a == b from (select '' a, '<31>' b); $ ./sqlite3 < test.sql CEB1|D031|0 CEB1|CEB1|1 It's necessary to validate subsequent bytes.
#e8e8bd 2327 new active 2007 Apr anonymous 2007 Apr anonymous 2 1 "DELETE" operation makes memory rise First declare a standard SQL script: delete from TableName where ....; Then calling repeatedly the sqlite3_exec() to process this "DELETE" operation. Surprisely the memory was rising fast, and couldn't be freed even the program exitted.
#e8e8bd 930 new active 2004 Sep anonymous Unknown 2007 Mar drh 2 2 djgpp port for sqlite3 hello, attached is a diff to sqlite 3.0.7 for dos, using free djgpp. i did it in the spirit of the isolated platform files, and the generic changes (such as creation of os_dependent functions) have been implemented for all platforms available. as required, the following copyright applies: The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights this code under copyright law. thanks for sqlite, and enjoy coding, alex p.s. i see that the diff i provided got mangled, and i'm changing it for the original one. since i'm unable to delete the wrong attachment, i would urge you to use the second one. alex
#e8e8bd 2238 new active 2007 Feb anonymous 2007 Feb 2 3 Streams as datbase Would it be possible to allow the use of streams as a database source? _2007-Feb-18 03:56:46 by anonymous:_ {linebreak} You'll have to be more precise in what you mean by that. SQLite needs to be able to do random access to the database data (ie seek all over the place according to how it is laid out). It also needs the ability to have a journal file alongside the database which is used when writing to do a rollback, or even for readers to know that a rollback needs to be done. I am not aware of any 'streams' that meet those criteria.
#e8e8bd 2220 new active 2007 Feb anonymous 2007 Feb drh 2 4 fsck for database files The existing recovery strategies for dealing with a corrupted database are entirely manual and could be improved with a reasonable amount of effort. One possible way to mitigate the issue would be the creation of an fsck recovery mechanism. This would be an improved recovery from the current .dump support.
#f2dcdc 2219 code active 2007 Feb shess 2007 Feb shess 2 2 Creating an fts table in an attached database works wrong. ATTACH DATABASE 'test2.db' AS two; CREATE VIRTUAL TABLE two.t2 USING fts2(content); will put t2_content, t2_segments, and t2_segdir in database 'main' rather than database 'two'. In some cases everything will appear to work, because the tables will be defaults for that name.
#e8e8bd 1126 new active 2005 Feb anonymous Unknown 2007 Jan drh 2 3 sqlite 2.8.16 port to djgpp here is a diff to be applied on sqlite 2.8.16 to make it work with djgpp. some of the fixes are needed for general purpose, such as relative path handling, and bypass of history and readline wherever not functional. dear drh, please apply this patch to mainstream sqlite. waiver of copyright in the patch itself. best regards, alex _2005-Feb-16 14:14:56 by drh:_ {linebreak} I applied these patches. But then the regression tests fail under unix. The patches much have broken something. No time to fix it now.... ---- _2005-Feb-17 11:46:57 by anonymous:_ {linebreak} thanks for your time. i will try to compile on linux and compare results. ---- _2005-Oct-11 14:58:05 by anonymous:_ {linebreak} i have to appologize for the long time it took me to get to it. i have found the flaw in the patch that made the fulltest fail on unix. now, that tests pass, please incorporate the diff in mainstream. i will fix the ports for sqlite3 too. ---- _2007-Jan-31 01:33:52 by anonymous:_ {linebreak} it seems someone has accidentally changed the diff i've provided for an invalid binary file.
#f2dcdc 2203 code active 2007 Jan anonymous 2007 Jan 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 2131 code active 2006 Dec anonymous 2006 Dec 2 3 Add substring() function (Part of SQL 99) sqlite> SELECT substring('foobar.class',-6,6) = '.class'; SQL error: no such function: substring sqlite> SELECT SUBSTRING('foobar.class',-6,6) = '.class'; SQL error: no such function: SUBSTRING sqlite> SELECT SUBSTR('foobar.class',-6,6) = '.class'; 1 sqlite> SELECT substring('foobar.class' FROM -6 FOR 6) = '.class'; SQL error: near "FROM": syntax error Looking at: http://www.oreilly.com/catalog/sqlnut/chapter/ch04.html SQL99 Syntax SUBSTRING(extraction_string FROM starting_position [FOR length] [COLLATE collation_name]) It would be useful for sqlite to support this syntax too to make the SQL more portable. _2006-Dec-28 16:03:03 by anonymous:_ {linebreak} sqlite has the substr() routine (func.c code): { "substr", 3, 0, SQLITE_UTF8, 0, substrFunc }, #ifndef SQLITE_OMIT_UTF16 { "substr", 3, 0, SQLITE_UTF16LE, 0, sqlite3utf16Substr }, #endif
this could be 'aliased' to help you using the substring() SQL99 std just doing: { "substr", 3, 0, SQLITE_UTF8, 0, substrFunc }, { "substring", 3, 0, SQLITE_UTF8, 0, substrFunc }, #ifndef SQLITE_OMIT_UTF16 { "substr", 3, 0, SQLITE_UTF16LE, 0, sqlite3utf16Substr }, { "substring", 3, 0, SQLITE_UTF16LE, 0, sqlite3utf16Substr }, #endif
#f2dcdc 2127 code active 2006 Dec anonymous 2006 Dec 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.
#f2dcdc 1946 code new 2006 Aug anonymous Unknown 2006 Dec 2 2 .read file fails on blob fields with end-of-file char I've a table with a blob fields. I put there binary data that contains 0x1a (end of file) symbol. It's alright until i try to dump table to file and then trying to import that file. sqlite3 my_db {linebreak}>.output my_file {linebreak}>.dump table_with_blob {linebreak}>.exit {linebreak}del my_db sqlite3 my_db {linebreak}>.read my_file Fails with "Incomplete SQL: ..." SQL break before 0x1a char I'm on windows. Possibly solving with opening file as binary file. Sorry for my English
#e8e8bd 2104 build active 2006 Dec anonymous 2006 Dec 2 3 manual link on Mac OS X fails due to common symbol Attempting a manual link on OS X with fts1: gcc -O -fPIC -dynamiclib -o mylib sqlite-3.3.8/*.o Results in the error: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option fts1.o definition of common _sqlite3_api (size 16) /usr/bin/libtool: internal link edit command failed This error is described: http://gcc.gnu.org/ml/gcc/2005-06/msg00199.html And a fix: --- /tmp/sqlite-3.3.8/src/sqlite3ext.h 2006-09-23 21:28:30.000000000 +1000 +++ sqlite3ext.h 2006-10-09 19:20:09.000000000 +1000 @@ -276,7 +276,7 @@ #define sqlite3_overload_function sqlite3_api->overload_function #endif /* SQLITE_CORE */ -#define SQLITE_EXTENSION_INIT1 const sqlite3_api_routines *sqlite3_api; +#define SQLITE_EXTENSION_INIT1 const sqlite3_api_routines *sqlite3_api = 0; #define SQLITE_EXTENSION_INIT2(v) sqlite3_api = v; #endif /* _SQLITE3EXT_H_ */
#f2dcdc 2093 code active 2006 Dec anonymous 2006 Dec 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.
#f2dcdc 2077 code active 2006 Nov anonymous 2006 Nov 2 1 Problems with using ASCII symbols 0x80 - 0xFF in database path Platform: Windows.
The SQLite library and executable doesn't see database files that are placed into folders named using ASCII symbols with codes 0x80-0xFF. That symbols are used to represent language-specific symbols (for example, Russian). In result, database cannot be placed into folder with name in Russian language. This bug is "unstable": it doesn't appear in all cases. Below are logs from my experiments with this problem. In all cases the path I requested exists, and database file is placed there. I have noticed that problem depends on filename path and name lengths. =========================================================
// creating test database
E:\!DISTRIB\sqlite-3_3_7>sqlite3.exe test.sqb
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> create table a(id int);
sqlite> insert into a values (1);
sqlite> ^C
E:\!DISTRIB\sqlite-3_3_7>copy test.sqb e:\test.sqb
'3'\'`'a'Z'b'`'S'Q'_'` 'f'Q'[']'`'S: 1. //This means that 1 file was copied
E:\!DISTRIB\sqlite-3_3_7>sqlite3 e:\test.sqb
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> select * from a;
1
sqlite> ^C
// Works!
E:\!DISTRIB\sqlite-3_3_7>mkdir e:\'/
//Using ASCII symbol "'/" (0x8D) to represent cyrillic letter which can be entered in the command line by using Alt+(141) combination
E:\!DISTRIB\sqlite-3_3_7>copy test.sqb E:\'/\test.sqb
'3'\'`'a'Z'b'`'S'Q'_'` 'f'Q'[']'`'S: 1.
E:\!DISTRIB\sqlite-3_3_7>sqlite3 e:\'/\test.sqb
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> select * from a;
1
sqlite> ^C
// That is works too!
E:\!DISTRIB\sqlite-3_3_7>mkdir E:\'/\1
E:\!DISTRIB\sqlite-3_3_7>copy test.sqb E:\'/\1\test.sqb
'3'\'`'a'Z'b'`'S'Q'_'` 'f'Q'[']'`'S: 1.
E:\!DISTRIB\sqlite-3_3_7>sqlite3 E:\'/\1\test.sqb
Unable to open database "E:\(T\1\test.sqb": unable to open database file
// Doesn't work, and writes the wrong symbol "(T" in place of "'/"! I've noticed that if we convert symbol "'/" from DOS encoding to Windows encoding and then write it in DOS encoding, then we'll get "(T".
E:\!DISTRIB\sqlite-3_3_7>copy test.sqb E:\'/\tst.sqb
'3'\'`'a'Z'b'`'S'Q'_'` 'f'Q'[']'`'S: 1.
E:\!DISTRIB\sqlite-3_3_7>sqlite3 E:\'/\tst.sqb
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> select * from a;
SQL error: no such table: a
sqlite> ^C
// It seems to work, i don't get an error, but doesn't see the tables! =(
=================================
#f2dcdc 2066 code active 2006 Nov anonymous 2006 Nov 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")
#e8e8bd 1998 build active 2006 Sep anonymous 2006 Sep 2 3 prefix option to configure ignored in tclinstaller.tcl schliep@karlin:~/tmp/sqlite-3.3.7> configure --prefix=/some/dir ... schliep@karlin:~/tmp/sqlite-3.3.7> make install tclsh ./tclinstaller.tcl 3.3 can't create directory "/usr/lib/tcl8.4/sqlite3": permission denied After commenting out all the stuff in ./tclinstaller.tcl things work
#e8e8bd 1996 new active 2006 Sep anonymous Unknown 2006 Sep drh 2 3 Data type CHAR An interface API for CHAR datatypes would really be helpful. For example, often sql tables contain CHAR(1) datatypes or CHAR(10) types. There should be some mechanism for handling these types natively. ie: sqlite3_bind_char sqlite3_column_char sqlite3_result_char sqlite3_value_char This will allow a more native implementation for CHAR datatypes, As it is, a single CHAR(1) must be first converted into a string (char[2]) and copied with a terminator. for CHAR types, not \000 termination is required. It is implied with the lenght. Thanks...
#f2dcdc 1983 code active 2006 Sep anonymous 2006 Sep 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.
#f2dcdc 1972 code active 2006 Sep anonymous 2006 Sep 2 4 segfault on empty query SQLite 2.8.17 used in latest versions of PHP segfaults with empty query (i.e. " ", 1 whitespace). PHP reproduce code: query(" ")); ?> GDB backrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1077220512 (LWP 3909)] 0x0814d227 in sqlite_step (pVm=0x0, pN=0x40364218, pazValue=0x40364210, pazColName=0x40364214) at /local/dev/php-src_5_2/ext/sqlite/libsqlite/src/vdbe.c:117 117 if( p->magic!=VDBE_MAGIC_RUN ){ (gdb) bt #0 0x0814d227 in sqlite_step (pVm=0x0, pN=0x40364218, pazValue=0x40364210, pazColName=0x40364214) at /local/dev/php-src_5_2/ext/sqlite/libsqlite/src/vdbe.c:117 #1 0x0812556a in pdo_sqlite2_stmt_execute (stmt=0x40364094) at /local/dev/php-src_5_2/ext/sqlite/pdo_sqlite2.c:102 #2 0x080bf4d5 in zim_PDO_query (ht=1, return_value=0x40363110, return_value_ptr=0x0, this_ptr=0x40363178, return_value_used=1) at /local/dev/php-src_5_2/ext/pdo/pdo_dbh.c:1033 #3 0x0824c1d6 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffca90) at /local/dev/php-src_5_2/Zend/zend_vm_execute.h:200 #4 0x0824c722 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffca90) at /local/dev/php-src_5_2/Zend/zend_vm_execute.h:322 #5 0x0824bde9 in execute (op_array=0x403637e4) at /local/dev/php-src_5_2/Zend/zend_vm_execute.h:92 #6 0x0822e66a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /local/dev/php-src_5_2/Zend/zend.c:1095 #7 0x081e7993 in php_execute_script (primary_file=0xbfffef00) at /local/dev/php-src_5_2/main/main.c:1759 #8 0x082933de in main (argc=2, argv=0xbfffefe4) at /local/dev/php-src_5_2/sapi/cli/php_cli.c:1102 (gdb) f 0 #0 0x0814d227 in sqlite_step (pVm=0x0, pN=0x40364218, pazValue=0x40364210, pazColName=0x40364214) at /local/dev/php-src_5_2/ext/sqlite/libsqlite/src/vdbe.c:117 117 if( p->magic!=VDBE_MAGIC_RUN ){ (gdb) p p $1 = (Vdbe *) 0x0 Proposed patch: http://cvs.php.net/viewvc.cgi/php-src/ext/sqlite/libsqlite/src/vdbe.c?r1=1.7.4.1&r2=1.7.4.1.2.1 _2006-Sep-10 11:10:26 by drh:_ {linebreak} PHP is calling sqlite_step() with a NULL sqlite_stmt pointer. This seems more like a bug in PHP than SQLite. I suggest patching PHP, somewhere in pdo_sqlite2.c I'm guessing, so that it checks to see if the statement pointer returned by sqlite_prepare() is NULL and skips the sqlite_step() and sqlite_finalize() calls if it is. The proposed patch above seems to confirm this strategy: The proposed patch would cause PHP to receive an SQLITE_MISUSE error. An SQLITE_MISUSE error indicates that the API is begin used incorrectly. The right fix, it seems to me, would be to use the API correctly. ---- _2006-Sep-10 15:40:46 by anonymous:_ {linebreak} "An SQLITE_MISUSE error indicates that the API is begin used incorrectly". I agree - and this simple NULL check would be the perfect place for SQLite to issue such a MISUSE error. Having SQLite recover from such a relatively common type of NULL input error would be beneficial to its users. SQLite already goes to great lengths to recover from out of memory situations. I don't see any reason not to add a simple "if NULL" check here to avoid crashing the the user's application. ---- _2006-Sep-10 16:56:12 by drh:_ {linebreak} I would quickly add such a change to SQLite version 3. And in fact I have already done so. See Ticket #870 and check-in [1906]. But we are talking about SQLite version 2, here, which is in maintenance mode and should not be used for new development. ---- _2006-Sep-10 20:05:41 by anonymous:_ {linebreak} >I suggest patching PHP, somewhere in pdo_sqlite2.c That's possible too, but currently I see no reasons to do it. >I'm guessing, so that it checks to see if the statement pointer returned by > sqlite_prepare() is NULL and skips the sqlite_step() and sqlite_finalize() calls if it is. The statement pointer in this case is (not) returned by sqlite_compile() call. Here is the piece of code: ... S->einfo.errcode = sqlite_compile(S->H->db, stmt->active_query_string, &tail, &S->vm, &errmsg); if (S->einfo.errcode != SQLITE_OK) { pdo_sqlite2_error_stmt(errmsg, stmt); return 0; } S->done = 0; S->einfo.errcode = sqlite_step(S->vm, &S->ncols, &S->rowdata, &S->colnames); ... From what I see, sqlite_compile() considers " " query as valid and doesn't return error, but in the same time the statement pointer remains NULL, which is clearly wrong. As I've said, it's easy to check if it's NULL or not in PHPs code, but I really think that the problem is in sqlite_compile().
#f2dcdc 1948 code active 2006 Aug anonymous Shell 2006 Aug 2 3 Double quotes are not escaped in csv mode If text is exported using "csv" mode, double quotes in strings are not escaped. Generally double-quotes in a quoted field in CSV should be escaped by repeate. I.e., 'This is a "test".' could be about as "This is a ""test""." This doesn't appear to be the behavior SQLite uses, so, in the meantime, I'll have to export my data using another method and then transform that data into CSV for my import script.
#e8e8bd 1939 event active 2006 Aug anonymous Unknown 2006 Aug 2 1 SQLite hangs with WHERE condition in an SELECT with joined table I have an database with 7 Tables. I wanted to make an SELECT in which i join the other Tables with an LEFT OUTER JOIN. That works but when i add an WHERE clause on an Joined Table my Application hangs. The sqlite3.exe hangs at the same query. My Database: CREATE TABLE MMBundesland (ID INTEGER, Bezeichnung varchar(255), Kennung INTEGER); CREATE TABLE MMCoords (ID INTEGER, Laenge DOUBLE, Breite DOUBLE, System varchar(50)); CREATE TABLE MMKFZ (ID INTEGER, Bezeichnung varchar(255)); CREATE TABLE MMKategorie (ID INTEGER,Bezeichnung varchar(255)); CREATE TABLE MMKreis (ID INTEGER, Bezeichnung varchar(255), Kennung INTEGER); CREATE TABLE MMOrte (ID INTEGER, CoordID INTEGER, Name varchar(255), KategorieID INTEGER, KreisID INTEGER, BundeslandID INTEGER, KfzID INTEGER, DefPLZID INTEGER, Kennung INTEGER); CREATE TABLE MMPLZ (ID INTEGER, PLZ varchar(10), CoordID INTEGER, OrtID INTEGER); The Query was: SELECT o.ID, o.Name,p.PLZ as DefPLZ,k.Bezeichnung,b.Bezeichnung as Bundesland, p.ID AS PLZID FROM MMOrte o LEFT OUTER JOIN MMPLZ p ON o.DefPLZID = p.ID OR o.ID = p.OrtID LEFT OUTER JOIN MMKategorie k ON o.KategorieID = k.ID LEFT OUTER JOIN MMBundesland b ON o.BundeslandID = b.ID LEFT OUTER JOIN MMPLZ p2 ON o.ID = p2.OrtID WHERE (p.PLZ like '72141%') ORDER BY o.Name Wenn I use: SELECT o.ID, o.Name,p.PLZ as DefPLZ,k.Bezeichnung,b.Bezeichnung as Bundesland, p.ID AS PLZID FROM *MMPLZ p* LEFT OUTER JOIN *MMOrte o* ON o.DefPLZID = p.ID OR o.ID = p.OrtID LEFT OUTER JOIN MMKategorie k ON o.KategorieID = k.ID LEFT OUTER JOIN MMBundesland b ON o.BundeslandID = b.ID LEFT OUTER JOIN MMPLZ p2 ON o.ID = p2.OrtID WHERE (p.PLZ like '72141%') ORDER BY o.Name The Query Works. It seems to work if i use in WHERE Clause one Column from the Table neer the FROM keyword. The main Problem is that SQLite hangs... I will generate my Query so that it works... _2006-Aug-25 13:32:21 by anonymous:_ {linebreak} "Hanging" is not very descriptive. Your query is working but now it either makes poor use of indexes or is doing full table scans, or possibly an unintended cross join. ---- _2007-Jan-10 16:31:41 by anonymous:_ {linebreak} I am seeing the same problem. It works on a limit of 1 and then fails on a limit of 2. ---- _2007-Jan-10 16:49:09 by drh:_ {linebreak} If you would like me to work on this, please send a reproducible test case.
#e8e8bd 1928 new active 2006 Aug anonymous Parser 2006 Aug 2 2 NULL rowid in views and subqueries $ cat rowid_on_views.sql create table abc(a,b,c); insert into abc values(4,5,6); insert into abc values(3,2,1); create view vv as select * from abc; select 'select rowid, * from abc;'; select rowid, * from abc; select 'select rowid, * from (select * from abc);'; select rowid, * from (select * from abc); select 'select rowid, * from vv;'; select rowid, * from vv; $ ./sqlite337 < rowid_on_views.sql select rowid, * from abc; 1|4|5|6 2|3|2|1 select rowid, * from (select * from abc); |4|5|6 |3|2|1 select rowid, * from vv; |4|5|6 |3|2|1 _2006-Aug-21 09:09:15 by anonymous:_ {linebreak} The point is simply that a view or subquery does not (meaning "cannot") have a rowid - just contemplate the case where your view takes the max(..) or count(..) of something. You would get the behaviour that you seem to expect when you declare your original table as create table abc(rowid integer primary key, a,b,c); ---- _2006-Aug-21 14:35:04 by anonymous:_ {linebreak} Not sure what you're talking about. Your example does not work. Many databases support the concept of "row id's" on views. It is a very useful construct. -- working Oracle example create table abc(a integer, b integer ,c integer); insert into abc values(4,5,6); insert into abc values(3,2,1); create view abc_vu as select * from abc; select rownum, a, b, c from (select * from abc_vu); ROWNUM A B C 1 4 5 6 2 3 2 1 -- another Oracle example select rownum, v1.*, v2.* from (select * from abc_vu) v1, (select * from abc_vu) v2; ROWNUM A B C A B C 1 4 5 6 4 5 6 2 3 2 1 4 5 6 3 4 5 6 3 2 1 4 3 2 1 3 2 1 ---- _2006-Aug-22 05:32:26 by anonymous:_ {linebreak} Hm, rowid (original ticket) and rownum (3rd remark) are very different things. I've tested the following with Oracle: create table abc(a integer, b integer ,c integer); insert into abc values(4,5,6); insert into abc values(3,2,1); insert into abc values(4,5,10); create view abc_vu as select max(a) as amax,b,count(*) as cnt from abc group by b; Now SQL> select rownum, amax,b,cnt from (select * from abc_vu); ROWNUM AMAX B CNT ---------- ---------- ---------- ---------- 1 3 2 1 2 4 5 2 whereas SQL> select rowid, amax,b,cnt from (select * from abc_vu); select rowid, amax,b,cnt from (select * from abc_vu) * ERROR at line 1: ORA-01446: cannot select ROWID from view with DISTINCT, GROUP BY, etc. ---- _2006-Aug-22 05:36:03 by anonymous:_ {linebreak} PS: selecting rowid from views without "group by" is supported by Oracle: SQL> create view abc_vu2 as select * from abc; View created. SQL> select rowid,a,b,c from (select * from abc_vu2); ROWID A B C ------------------ ---------- ---------- ---------- AAADmaAAFAAAFNzAAA 4 5 6 AAADmaAAFAAAFNzAAB 3 2 1 AAADmaAAFAAAFNzAAC 4 5 10
#f2dcdc 1901 code active 2006 Jul anonymous Unknown 2006 Jul 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
#f2dcdc 1885 code active 2006 Jul anonymous Shell 2006 Jul 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.
#f2dcdc 1878 code active 2006 Jun anonymous CodeGen 2006 Jun 2 3 No index used when specifying alias name in ORDER BY clause Using an alias name in the ORDER BY clause prevents indices from being used in the query for sorting purposes: For this schema: CREATE TABLE t1 (c1, c2); CREATE TABLE t2 (c3, c4); CREATE INDEX t1_idx ON t1(c2); the following select query: EXPLAIN QUERY PLAN SELECT t1.c2 AS col2, t2.c4 AS col4 FROM t1 LEFT JOIN t2 ON t1.c1=t2.c3 ORDER BY t1.c2; will indeed use index t1_idx: sqlite> EXPLAIN QUERY PLAN SELECT t1.c2 AS col2, t2.c4 AS col4 FROM t1 LEFT JOIN t2 ON t1.c1=t2.c3 ORDER BY t1.c2; 0|0|TABLE t1 WITH INDEX t1_idx 1|1|TABLE t2 However, when using the alias name =col2= in the =ORDER BY= clause, the index won't be used: sqlite> EXPLAIN QUERY PLAN SELECT t1.c2 AS col2, t2.c4 AS col4 FROM t1 LEFT JOIN t2 ON t1.c1=t2.c3 ORDER BY col2; 0|0|TABLE t1 1|1|TABLE t2 IMHO, the same index should be used in both queries? _2006-Jun-30 13:54:10 by anonymous:_ {linebreak} Not sure whether it's a different issue, but when using a second column in the ORDER BY clause, also no index will be used: sqlite> EXPLAIN QUERY PLAN SELECT t1.c2 AS col2, t2.c4 AS col4 FROM t1 LEFT JOIN t2 ON t1.c1=t2.c3 ORDER BY t1.c2, t2.c4; 0|0|TABLE t1 1|1|TABLE t2 Personally, I'd expect sqlite to use the =t1_idx= index as well to fulfill the primary ordering? ---- _2006-Jun-30 16:04:31 by anonymous:_ {linebreak} As a workaround try "ORDER BY 1" ---- _2006-Jul-03 08:41:01 by anonymous:_ {linebreak} Sorry, I'm not sure how "ORDER BY 1" would be a workaround, when I really need the results to be sorted by table column data... (I don't want to start a discussion in the bug tracker, so you're welcome to take any suggestions/answers to the sqlite-user mailing list, which I also monitor.) ---- _2006-Jul-03 15:51:11 by anonymous:_ {linebreak} I'm not the poster of previous comment, but ORDER BY (n) order by result column index. In your case, using ORDER BY 1, it will be ordered by the first column. ---- _2006-Jul-04 07:33:30 by anonymous:_ {linebreak} Thanks for the clarification. This would be a workaround for the first problem mentioned, but when sorting by two columns, still no index will be used, even if using =ORDER BY 1,2= ---- _2006-Jul-04 21:34:24 by anonymous:_ {linebreak} SQLite really needs a way to explicitly state which index(es) to use. Perhaps something similar to Oracle's comment hints.
#e8e8bd 1874 new active 2006 Jun anonymous CodeGen 2006 Jun 2 3 IN is much slower than making separate queries I have a 500,000-row table with the following schema: CREATE TABLE foo(bar INTEGER NOT NULL, baz INTEGER NOT NULL, biz INTEGER NULL, buzz INTEGER NULL); CREATE INDEX biz ON foo (bar, baz, biz); CREATE INDEX buzz ON foo (bar, baz, buzz); I'm performing the query: SELECT * FROM foo WHERE bar IN (0,1) AND baz IN (0,1) AND (biz IN (0,1) OR buzz IN (0,1)); On both Apple's 3.1.3 and a stock 3.3.6 on Mac OS X 10.4.6 PowerPC, this query consistently takes 3 seconds to execute. However, if I unroll the query: SELECT * FROM foo WHERE bar=0 AND baz=0 AND biz=0; SELECT * FROM foo WHERE bar=0 AND baz=0 AND buzz=0; ...and so on for the other values of bar and baz... it takes 0.2 seconds. I was able to reproduce this with the attached scripts by doing: ./mkdb > mkdb.sql sqlite3 testdb < mkdb.sql time sqlite3 testdb < q1 > /dev/null time sqlite3 testdb < q2 > /dev/null The database was recreated between the 3.1.3 and the 3.3.6 testing. EXPLAIN on the IN query segfaults on both 3.1.3 and 3.3.6, otherwise I'd attach that output. I'll write up a separate bug for that :) _2006-Jun-27 20:52:35 by anonymous:_ {linebreak} [3315] fixed the EXPLAIN crash, so I've attached EXPLAIN output for the IN query. ---- _2006-Jun-27 22:01:31 by drh:_ {linebreak} On SuSE Linux 10.0 running on a Dell Latitude D600 laptop and using the latest code from CVS, I'm getting times of 1.2s and 0.45s. If I create an additional index: CREATE INDEX i2 ON foo(bar,baz,biz,buzz); then the time for the first query drops to 0.7s. Note, however, the q1 and q2 are very different queries. In particular q2 omits half the rows. The (rough) equivalent of q2 is this: SELECT * FROM foo WHERE bar IN (0,1) AND baz IN (0,1) AND (biz=0 or buzz=0); If I modify q2 so that it includes the biz=1 and buzz=1 cases, its query time increases to 0.7s, the same as q1 with the added index. Further note that q1 and q2 are still not exactly the same. Q2 includes multiple copies of rows where biz IN (0,1) AND buzz IN (0,1) where q1 only includes such lines once. There are only 120 such lines in the database, but it still a difference. I will recast this ticket as a request for performance enhancements on queries using the IN operator on a fixed list of values. ---- _2006-Jun-28 01:52:32 by drh:_ {linebreak} Note to self: The expression +x IN (1,2,3,...) appears to be faster than +x=1 OR +x=2 OR ... when there are 6 or more terms. With 5 terms or fewer, a string of ORs is faster.
#e8e8bd 1871 event active 2006 Jun anonymous 2006 Jun 2 3 VACUUM should not change 3.x file format VACUUM should not "upgrade" the file format as it violates the principle of least astonishment. VACUUM upgrading the file format prevents users working with older versions of SQLite 3.x from sharing a common database file with users of more recent versions of the library. At the very least, if a version of SQLite can not produce the same version of the database file after VACUUM, it should do nothing, or perhaps return a warning. _2006-Jun-27 13:25:30 by drh:_ {linebreak} What if a user wants to upgrade the file format so that they can take advantage of descending indices, for example? How should they accomplish that? Should they be forced to dump and restore the database? ---- _2006-Jun-27 14:10:16 by anonymous:_ {linebreak} Manually dumping the old database and restoring it with a more recent version of SQLite is reasonable given the incompatible nature of the change. ---- _2006-Jun-27 15:30:32 by anonymous:_ {linebreak} I agree. Can't SQLite do the equivalent of pragma legacy_file_format=1 on the new database created by the VACUUM command if the current file is in the old format? The dump and restore operation is usable for updating the file format, but does require two installed versions of SQLite, one old and one new. Couldn't you add a new command or pragma that would do the format upgrade. Perhaps an optional upgrade argument to the VACUUM command that defualts to off could be used. If it is off the format of the new database is unchanged, if it is on, the format is upgraded. The VACUUM command doesn't seem like the obvious place tto look for a format upgrade option though. A new UPGRADE command would be more obvious, even if it is actually implemented by the same routines that do the VACUUM. It may be better to use something a little lower profile than a new command, perhaps a "PRAGMA upgrade_file_format" would be better. It would also allow future extension to provide a format version number that the database is to be upgraded to (ie PRAGMA upgrade_file_format=4). ---- _2006-Jun-27 17:55:23 by anonymous:_ {linebreak} it's a simple issue. since SQLite know the file format of database that is opened, on VACUUM it should create a file with the same version (such like a internal _sqlite3_open_ex() call that receive the file format that should be created. since SQLite can read/write those formats, there's no reason for doing a 'file format' upgrade.
#f2dcdc 1856 code active 2006 Jun anonymous 2006 Jun 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.
#f2dcdc 1851 code active 2006 Jun anonymous Unknown 2006 Jun 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.
#f2dcdc 1850 code active 2006 Jun anonymous Unknown 2006 Jun 2 1 NUMERIC data type ERROE when read on uClinux I have update some data of a tables's NUMERIC TYPE column on Windows or Linux,but when I use "select *......." to read on uClinux 2.4.24,I get the wrong value,example:the date I've written is 12.5,but readback is 2.3534826093695e -18.5(use the sqlite3_column_text API). I tried to get the value used "sqlite3_column_double" API,but the result is also wrong; But when I update some data with this column on uClinux,I can read the data right! _2006-Jun-16 01:53:24 by drh:_ {linebreak} What CPU is this happening on? SQLite assumes that floating point values are stored as IEEE 64-bit floats in the same byte order as a 64-bit integer. If your chip does not match this expectation, then floating point won't work.
#f2dcdc 1799 code active 2006 May anonymous Pager 2006 May 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.
#f2dcdc 1777 code active 2006 Apr anonymous 2006 Apr 2 4 Cygwin should be OS_UNIX target, not OS_WIN Cygwin, a UNIX emulation layer on Windows, should be an OS_UNIX target (not an OS_WIN target) in order to use the UNIX filesystem calls and paths. The Cygwin GNU debugger gdb will not work correctly with a Cygwin sqlite3 built with -DOS_WIN=1 (trust me - I wasted an hour on determining why database files cannot open under cygwin/gdb). MinGW, on the other hand should remain an OS_WIN target. All references to cygwin should be removed from os.h, and configure.ac should have something like this pseudo-code: if test "$CYGWIN" = "yes"; then OS_UNIX=1 OS_WIN=0 tclsubdir=unix TARGET_CFLAGS="$TARGET_CFLAGS -DOS_UNIX=1" elif test "$TARGET_EXEEXT" = ".exe"; then OS_UNIX=0 OS_WIN=1 tclsubdir=win TARGET_CFLAGS="$TARGET_CFLAGS -DOS_WIN=1" else OS_UNIX=1 OS_WIN=0 tclsubdir=unix TARGET_CFLAGS="$TARGET_CFLAGS -DOS_UNIX=1" fi Once sqlite3 thinks it is an OS_UNIX library under cygwin, all the strange problems I've been experiencing go away. _2006-Apr-19 12:07:34 by anonymous:_ {linebreak} Although gdb sqlite3.exe debugging is functional and cygwin file paths work better with OS_UNIX=1, it seems that some cygwin file locking primitives only work with OS_WIN=1.
#f2dcdc 1754 code active 2006 Apr anonymous Pager 2006 Apr 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 1742 code active 2006 Mar anonymous Unknown 2006 Mar drh 2 3 ORDER BY on more than one column causes a big slowdown Put simply, any query which contains an ORDER BY clause that sorts on more than one column incurs a strange slowdown. Running SQLite 3.3.4 on WindowsXPSP2 and on OS X 1.4.5, the behavior is similar; if the ORDER BY clause contains one column, the query is very fast; on two or more columns, it is terribly slow. _2006-Mar-28 23:58:15 by anonymous:_ {linebreak} Also worth noting that this behavior seems to start with SQLite 3.3.x; earlier versions of SQLite handle multiple ORDER BY columns much faster. ---- _2006-Mar-29 01:22:11 by anonymous:_ {linebreak} Note also that this behavior is being exhibited when sorting on *indexed* columns ---- _2006-Mar-29 01:50:38 by drh:_ {linebreak} Some examples would be helpful. ---- _2006-Mar-29 18:11:43 by anonymous:_ {linebreak} Most definitely! I will attach a sample 3.3.4 database dump, that displays this behavior.
#f2dcdc 1700 code active 2006 Mar anonymous Parser 2006 Mar 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.
#e8e8bd 1689 new active 2006 Feb anonymous 2006 Mar 2 4 triggers and temporary tables CREATE TRIGGER trg_upd_dict AFTER UPDATE ON dict BEGIN UPDATE dict SET code = (SELECT code from tmp_connected_user) WHERE old.dict_id = dict_id ; END ;
This trigger doesn't work if tmp_connected_user is a temporary table. The message is : SQL error: no such table: main.tmp_connected_user The goal is to have persistant triggers who works with temporary tables. Exemple of use : - Workarround who replace the non existing connection by user / password. When we insert/update, the database doesn't know who insert/update. If we have a table user, we can on each table fill by trigger fields like last_user_id, last_modif_d. The trigger cannot know who make the connection but we stock the user_id when he connects to the db in a temporary table, the trigger will work. - Security (no one can update / insert the database if a special temporary table is not created and filled). ---- _2006-Mar-03 20:25:41 by drh:_ {linebreak} You can create a TEMP trigger that will reference tables in the main database and/or attached databases. But SQLite currently does not allow triggers in the main or attached database to reference tables in other databases. I will enter this as an enhancement request. ---- _2006-Mar-06 16:17:11 by anonymous:_ {linebreak} Workarround for this ticket : if we only need 1 result, we can use user defined function instead temporary table in the trigger. Tested with php : it works :)
#e8e8bd 1703 new active 2006 Mar anonymous Pager 2006 Mar 2 3 Second parameter to gettimeofday() in os_unix.c should be NULL in os_unix.c, function sqlite3UnixCurrentTime(): the second argument to gettimeofday() should be NULL and the declaration of sTz should be removed. struct timezone seems to cause trouble on Linux systems.
#e8e8bd 1555 doc active 2005 Dec anonymous BTree 2005 Dec appledev 2 4 sqlite+Crystal reports connection I have problem of sqlite and crystal report connection
#e8e8bd 1543 build active 2005 Nov anonymous 2005 Nov 2 1 File encrypted or corrupted while using french characters Hi, if we use the french characters in the database file path as i mentioned the characters above is throwing the error while creating a new database file or connecting with old one using realbasic as front end. _2005-Nov-29 18:33:20 by drh:_ {linebreak} Why do you think this is a problem with SQLite and not with realbasic? ---- _2005-Nov-29 20:16:12 by anonymous:_ {linebreak} If this happens using the REALbasic wrapper for SQLite, then the bug is definitely in the wrapper and not in SQLite. The bug has been fixed and should appear in the next version of REALbasic. ---- _2005-Nov-30 06:32:25 by anonymous:_ {linebreak} Dear drh; In real basic folderitem is working fine with this french characters. i am getting this error in the line as "if db.connect then" it throws false and the error message shown as "File is encrypted or not a database file". Please confirm this problem is not with SqLite while using the following characters ÀàÁáÂâÃãäÄÅåÈèÉéÊêËëÌìÍíÎîÏïÒòÓóÔôÕÖö. with Thanks, Vinoth. Vino_it@hotmail.com
#f2dcdc 1542 code active 2005 Nov anonymous Unknown 2005 Nov 2 4 wrong field names in views with quoted table name qualifiers SQLite returns wrong field names in views using quoted table name qualifiers. Examples: The following statement create view custview as select [customer].company from customer creates a view with one field: customer (should be company) The next one: create view custview as select [customer].company, [customer].address from customer creates a view with two fields: customer and customer:1 (should be company and address) Reproduced with version 3.2.7 on Win32.
#f2dcdc 1502 code active 2005 Oct anonymous Unknown 2005 Oct 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
#f2dcdc 1458 code active 2005 Sep anonymous Shell 2005 Sep 2 2 Error at .importing in csv format (another) Sqlite3 version 3.2.6 : When importing data in csv format the programa adds commas when importing strings enclosed with commas in the source file. In particular it shouldnt add commas when field data is already enclosed in comma, but it does. Curiously enough, it correctly imports numeric data. Example: Take de demodatabase file, and take the table clients. If you try to add these records to the table with .import, it is impossible (the only workaround is deleting commas in the file and importing it in 504,"New Enterprise","Mr Smart","93-2275400"{linebreak} 505,"Another Enterprise","John Dongu","93-8765432"{linebreak} 506,"And here we are","Mr Strange","973-237131"{linebreak} This file would be impossible to import correctly with .import If you set .mode list, it is imported incorrectly, since it keeps the commas around character fields in the table -which is what it should do anyway, since in this mode the program does not expect commas around field data. But when you set <.mode csv>, it imports them also incorrectly - it adds new commas around character data. Souce data in csv format is important, -probably the most general data format available, and often a last resort format for difficult cases... Thank in advance. I would like to help at fixing problems myself, but I do not understand a word of C. Antoni Francino afrancino@mesvilaweb.com _2005-Sep-27 23:07:43 by anonymous:_ {linebreak} You've got the names of your punctuation characters confused. What's happening is that the _double quote marks_ around the text fields are gettting imported, whereas the usual understanding of "CSV" is that they should be stripped off. ---- _2005-Sep-27 23:11:27 by anonymous:_ {linebreak} On further inspection, this turns out to be the same problem as in ticket #1312.
#e8e8bd 1426 event active 2005 Sep anonymous Unknown 2005 Sep drh 2 2 Problem with DETACH in 2.8.16 sqlite1.txt: create table documents (a); create index i on documents(a); sqlite2.txt: attach 'x1.dbx' as d1; attach 'x2.dbx' as d2; detach d1; Commands: sqlite x1.dbx#!/bin/sh RPM_SOURCE_DIR="/home/jms1/rpm/SOURCES" RPM_BUILD_DIR="/home/jms1/rpm/BUILD" RPM_OPT_FLAGS="-O2 -g -march=i386 -mcpu=i686" RPM_ARCH="i386" RPM_OS="linux" export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS RPM_DOC_DIR="/usr/share/doc" export RPM_DOC_DIR RPM_PACKAGE_NAME="sqlite" RPM_PACKAGE_VERSION="3.2.1" RPM_PACKAGE_RELEASE="1" export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE RPM_BUILD_ROOT="/var/tmp/sqlite-3.2.1-root" export RPM_BUILD_ROOT set -x umask 022 cd /home/jms1/rpm/BUILD cd sqlite-3.2.1 install -d $RPM_BUILD_ROOT//usr install -d $RPM_BUILD_ROOT//usr/bin install -d $RPM_BUILD_ROOT//usr/include install -d $RPM_BUILD_ROOT//usr/lib make install prefix=$RPM_BUILD_ROOT//usr /usr/lib/rpm/brp-compress /usr/lib/rpm/brp-strip /usr/lib/rpm/brp-strip-static-archive /usr/lib/rpm/brp-strip-comment-note
and when it runs, it generates the following output: Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.11845 + umask 022 + cd /home/jms1/rpm/BUILD + cd sqlite-3.2.1 + install -d /var/tmp/sqlite-3.2.1-root//usr + install -d /var/tmp/sqlite-3.2.1-root//usr/bin + install -d /var/tmp/sqlite-3.2.1-root//usr/include + install -d /var/tmp/sqlite-3.2.1-root//usr/lib + make install prefix=/var/tmp/sqlite-3.2.1-root//usr tclsh ./tclinstaller.tcl 3.2 can't create directory "/usr/share/tcl8.4/sqlite3": permission denied while executing "file mkdir $LIBDIR/sqlite3" (file "./tclinstaller.tcl" line 15) make: *** [tcl_install] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.11845 (%install)
looking at tclinstaller.tcl, it looks like it sets DESTDIR to an empty string if the variable doesn't already exist (i will admit i'm guessing here, i'm not an expert with tcl) which causes LIBDIR to point to "/usr/share/tcl8.4" (instead of "/var/tmp/sqlite-3.2.1-root/usr/share/tcl8.4", which is what one would expect.) the "rpmbuild" process, running as non-root, doesn't have permission to create this system directory, hence the error message. i don't know enough about tcl to figure out how to make DESTDIR carry into the script correctly, or even how to debug it to make sure that's what's actually going on.
#f2dcdc 1214 code active 2005 Apr anonymous Unknown 2005 Apr 2 3 sqlite3_column_bytes returns 0 on p3 column with EXPLAINed selects Both functions sqlite3_column_bytes() sqlite3_column_bytes16() do not return the correct length for the p3 text column of EXPLAIN select queries. Both functions always return 0, even if the p3 column contains text. The bug can be easily reproduced with the following query: EXPLAIN SELECT 'text'; The p3 column, row 2, contains the word 'text', but the functions return 0 regardles. I have not seen this bug with non EXPLAIN queries, but it breaks code which relies on the fact that sqlite3_column_bytes always retun the correct length of the text and needs to preallocate memory accordingly.
#f2dcdc 1030 code active 2004 Dec anonymous Shell 2005 Apr 2 3 impossible to import a file and do other things in the same invocation (strongly affects scripting) The sqlite2 shell can be scripted in 2 ways: 1. sqlite mydb 'commands' 2. commands | sqlite mydb The first form has a bug, which I have not submitted, and which also occurs in sqlite3: o dot commands are not fully intermixable with sql commands It will also fail for long command lines. To work around this, it is necessary to use the second form of scripting. However: o for entering data via COPY or .import, a separator is necessary to allow sql after the data o COPY has \. as a separator Here is the sqlite3 bug: o .import has no separator that I know of The only possible workaround seems to be to call the executable more than once. However: o this makes :memory: databases impossible Therefore, I said this is major with a workaround. The workaround is to use temporary files instead of memory databases, and: o inconveniently kludge the sqlite2 behavior using multiple calls to the executable However, files are far slower than memory, making the use of sqlite as an awk-like filter less attractive than it was with sqlite2. Here are 2 solutions to fix the problem, both of which are desirable: o allow dot commands and sqlite commands to be intermixable on the command line such as with "sqlite :memory: '.show;.import ...;select ...;.import ...; select ...'" o allow a separator for .import Here are some related bugs, also not submitted: o .separator is overloaded to mean input and output separators, but for scripting it would be useful to have them separate o csv mode and tabs mode are lightly documented. what are the exact syntaxes for them (line continuation, quoting, etc.), and what is the difference between tabs mode and .separator set to tab? o it might also be useful to have a .with command so that you can do .with .separator ","; .import ...; .endwith to effectively emulate (let ((...)) ...) in lisp. i.e. temporarily set a value to something without having to know what to set it back to when you are done. Sqlite rocks. Thanks.
#f2dcdc 1200 code active 2005 Apr anonymous 2005 Apr 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.
#f2dcdc 1191 code active 2005 Mar anonymous Unknown 2005 Mar 2 3 last_insert_id() Does Not Work after Insert on View If I have a view with an INSERT trigger attached to it, and then use the view to insert a record, last_insert_rowid() does not return the ID inserted. For example, given this DDL: CREATE TABLE _simple ( id INTEGER NOT NULL PRIMARY KEY, name TEXT ); CREATE VIEW simple AS SELECT _simple.id AS id, _simple.name AS name FROM _simple; CREATE TRIGGER insert_simple INSTEAD OF INSERT ON simple FOR EACH ROW BEGIN INSERT INTO _simple (name) VALUES (NEW.name); END; This is what I get when I use the view to insert: sqlite> insert into simple (name) values ('foo'); sqlite> select last_insert_rowid(); last_insert_rowid() ------------------- 0 It does work if I insert directly into the table, of course: sqlite> insert into _simple (name) values ('foo'); sqlite> select last_insert_rowid(); last_insert_rowid() ------------------- 2 _2005-Mar-31 06:04:59 by anonymous:_ VIEWs are read-only so you can not INSERT into them. See: http://www.sqlite.org/omitted.html Regards, Bartosz. ---- _2005-Mar-31 18:12:10 by anonymous:_ {linebreak} Bartosz, Please note that triggers have been applied to the view, so you can actually insert into them. I do it all the time. For example, given my previous examples, this insert will work: sqlite> insert into simple (id, ame) values (1, 'foo'); Pretty coole, eh? See: http://www.sqlite.org/lang_createtrigger.html --Theory ---- _2005-Mar-31 18:21:08 by drh:_ {linebreak} The last_insert_rowid() routine *does* return the correct insert rowid while you are still within the trigger. Once you leave the trigger, last_insert_rowid() returns the rowid of the most recently inserted row outside of any trigger. This is by design. If last_insert_rowid() were to be responsive to inserts done by triggers, then any AFTER INSERT trigger that happened to update a logfile would overwrite the last_insert_rowid() from the actual INSERT. One could argue, I suppose that last_insert_rowid() should work for inserts performed by an INSTEAD OF trigger but not by other kinds of triggers. I will ponder that notion and might implement it if I cannot think of any objections. ---- _2005-Mar-31 18:25:14 by anonymous:_ {linebreak} Allowing it to persist past the trigger in an INSTEAD OF trigger would certainly do what I need. I think that'd make a lot of sense. All of this should probably be well-documented somewhere. I'd be happy to add a page to the wiki once you've decided how to proceed with this issue. Thanks! Theory ---- _2005-Apr-27 02:21:21 by anonymous:_ {linebreak} Have you had a chance to think more on this issue? Thanks, Theory ---- _2005-Nov-08 03:06:51 by anonymous:_ {linebreak} Just checking in on this issue again. Do you think that it's something that will be resolved, one way or the other, soon? Thanks, Theory ---- _2005-Nov-08 17:44:14 by anonymous:_ {linebreak} The instead of insert trigger can't, in general, update the last_insert_rowid value automatically and do it correctly, since a trigger may do multiple inserts into multiple tables. SQLite has no idea which rowid should be reported back outside the trigger. This is left to the user (i.e. the author of the trigger). You can get the last_insert_rowid after the appropriate insert in the trigger and then save that value into an auxillary table that is visible outside the trigger. This is especially important when your view is created from entries in several joined tables. Your instead of insert trigger must do inserts into the individual tables, and may need to use the last_insert_rowid function to link the records in the tables together correctly. It then needs to return the "master" rowid for the table. SQL doesn't have any syntax to specify which value is returned as the rowid of the instead of trigger, so SQLite doesn't do anything automatically. You need to create a sperate last_rowid table, and inside the trigger you update the value of a row in that table (possibly the only row) with the value you want to return. Then the code that does the insert into the view needs to get the value of that row instead of calling last_insert_rowid. This type of behavior is needed since there is no limit to the number of nested instead of triggers that could be executed by a single SQL statement (i.e. one instead of trigger could do an insert into another view... and so on). The current behavior isn't quite as convenient in the simplest case, but it works correctly in the more complicated general case, where simply updating the last_insert_rowid value would be wrong. ---- _2005-Nov-08 22:51:56 by anonymous:_ {linebreak} I think that there's an argument to be made that last_insert_rowid() should return the last inserted row ID, even if a trigger inserted a bunch. It should simply return the last one entered. However, I agree with your analysis. Could there perhaps be a set_insert_id() function, or some such, that the trigger could use to tell last_insert_row_id() what to return?
#f2dcdc 1149 code active 2005 Feb anonymous 2005 Feb 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.
#e8e8bd 1128 event active 2005 Feb anonymous Shell 2005 Feb 2 3 sqlite3-3.1.2.bin segfaults Linux 2.4.26 (Knoppix 3.4 on hard drive) download: http://sqlite.org/sqlite3-3.1.2.bin.gz attached: strace log In the strace log I notice that the segfault happens just after /etc/nsswitch.conf has been read, if that's of any consequence.
#f2dcdc 1085 code active 2005 Jan anonymous 2005 Jan 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.
#f2dcdc 1078 code active 2005 Jan anonymous 2005 Jan 2 3 Lemon destructor bugs that don't affect sqlite I found a few bugs Lemon's destructor handling code. I don't think that they affect sqlite, but the do affect other grammars. - The code that collapses cases for default destructors erroneously assumes that all symbols have the same type. - If a reduction rule doesn't have code, then the RHS symbols will not have their destructors called. - The default destructor shouldn't be called on the auto-generated "error" symbol - In the internal function "append_str", zero-length strings may be returned un-terminated. I have some proposed fixes that I'll try to attach to this ticket. _2005-Jan-14 13:33:52 by drh:_ {linebreak} Do you also have some test grammars? That would really be helpful. ---- _2005-Jan-14 17:14:15 by anonymous:_ {linebreak} Sure. Here is one grammar that will demonstrate the "Tokens leak when rule has no code" bug: %token_type { char * } %token_destructor { printf("Deleting token '%s' at %x\n", $$, (int)$$); free($$); } result ::= nt. nt ::= FOO BAR.
Running the following code against the grammar should theoretically show 2 allocations and two destructions. It won't though, unless you modify the rule for nt to have an empty body, like: {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 */ } }
#e8e8bd 1034 build active 2004 Dec anonymous TclLib 2004 Dec 2 4 configure generated Makefile doesn't use TCL on MinGW on Windows When using MinGW/MSYS on Windows XP, the Makefile generated by the configure script fails while building the testfixture. The makefile is generated using ../sqlite/configure --with-tcl=/c/mingw/lib The configure script correctly locates the tclConfig.sh file in this directory and loads it. When I try to run the test suite, the build fails while linking the testfixture as shown below: $ make test ./libtool --mode=link gcc -g -O2 -DOS_WIN=1 -I. -I../sqlite/src -DNDEBUG -I/mingw/include -DSQLITE_OMIT_CURSOR -DTCLSH=1 -DSQLITE_TEST=1\ -DTHREADSAFE=0 -DTEMP_STORE=2\ -o testfixture ../sqlite/src/btree.c ../sqlite/src/date.c ../sqlite/src/func.c ../sqlite/src/os_mac.c ../sqlite/src/os_unix.c ../sqlite/src/os_win.c ../sqlite/src/pager.c ../sqlite/src/pragma.c ../sqlite/src/printf.c ../sqlite/src/test1.c ../sqlite/src/test2.c ../sqlite/src/test3.c ../sqlite/src/test4.c ../sqlite/src/test5.c ../sqlite/src/utf.c ../sqlite/src/util.c ../sqlite/src/vdbe.c ../sqlite/src/md5.c ../sqlite/src/tclsqlite.c \ libtclsqlite3.la gcc -g -O2 -DOS_WIN=1 -I. -I../sqlite/src -DNDEBUG -I/mingw/include -DSQLITE_OMIT_CURSOR -DTCLSH=1 -DSQLITE_TEST=1 -DTHREADSAFE=0 -DTEMP_STORE=2 -o testfixture ../sqlite/src/btree.c ../sqlite/src/date.c ../sqlite/src/func.c ../sqlite/src/os_mac.c ../sqlite/src/os_unix.c ../sqlite/src/os_win.c ../sqlite/src/pager.c ../sqlite/src/pragma.c ../sqlite/src/printf.c ../sqlite/src/test1.c ../sqlite/src/test2.c ../sqlite/src/test3.c ../sqlite/src/test4.c ../sqlite/src/test5.c ../sqlite/src/utf.c ../sqlite/src/util.c ../sqlite/src/vdbe.c ../sqlite/src/md5.c ../sqlite/src/tclsqlite.c ./.libs/libtclsqlite3.a -L/mingw/lib -ltclstub84 C:/DOCUME~1/DennisC/LOCALS~1/Temp/cc2taaaa.o(.text+0x511): In function `sqlite3TestErrCode': c:/SQLite/SQLiteV3/build2/../sqlite/src/test1.c:77: undefined reference to `_imp__Tcl_ResetResult' It looks like the code is being linked against the tclstub84 library which doesn't contain the needed code. To work around this problem, I needed to modify the Makefile that configure generated. I modified the line: LIBTCL = to use the correct library like this: LIBTCL = -L/mingw/lib -ltcl84 Now the testfixture builds correctly and I can run the test suite. Someone more familiar with the automake tools will need to correct this problem on a more permanent basis. _2004-Dec-10 02:15:25 by drh:_ {linebreak} You can help us to troubleshoot this by attaching the following files to the ticket: *: tclConfig.sh *: the complete output of configure and make ---- _2004-Dec-10 16:08:05 by anonymous:_ {linebreak} I have attached the requested files. Note, these files were generated from the latest CVS source after checkin 2162. The tclConfig.sh file is exactly as is was installed by the MinGW tcltk binary package in the last stable version of MinGW/MSYS (I just checked and they have released a newer stable version of MinGW/MSYS since I installed mine. It seems the only package which is newer than my installation is the gcc compiler. I have the current version of the tcl/tk package.)
#e8e8bd 971 todo active 2004 Oct anonymous Unknown 2004 Oct peter 2 1 how to recompile sqlite with THREADSAFE preprocessor macro set to 1? I have just installed sqlite-2.8.15 on my linux machine. After that I've tried to run the sqlite.php file which returns the fatal error as like below: Call to undefined function: sqlite_open() in /home/maintain/public_html/tmp/sqlite.php on line 2 As per the instruction given in the forum, I have learn that I have to recompile the sqlite with THREADSAFE preprocessor macro set to 1, but I really don't know how to do this. Kindly help me on this issue. Thanks and Regards, Rajesh Kannan M
#e8e8bd 864 build active 2004 Aug anonymous Unknown 2004 Aug 2 2 3.0.4 uses readling on netbsd, I was compiling sqlite. It tried to use the readline library even though it did not exist. I edited the makefile to not use readline and it works, but config should have done this. Also, the best fix on the *BSDs is to also detect and use libedit instead of libreadline. _2004-Sep-16 08:47:00 by anonymous:_ {linebreak} I don't know how to add the logic to the config system, but on BSD systems with libedit, changing the makefile to read LIBREADLINE = -ledit -ltermcap allows it to compile and use libedit. On some older versions of NetBSD it was also needed to ln the header files to where sqlite it looking for them. Newer versions worked with just the Makefile change above.
#e8e8bd 815 build active 2004 Jul anonymous 2004 Jul 2 1 SQLite3.dll exports The SQLite3.dll does not export all of its documented api. I.e. SQLite_gettable/freetable is not exported. This is a similar error as before and can be easily fixed (I think) since I can download a correct dll from www.squeakycode.net (one of the other sqlite users). Since the exports are mentioned in the .def file I think there might be an error in the build of the windows dll. (without tcl bindings). I like to deploy my (freeware) delphi components for version 3, but they require the squeakycode dll. This is a nice temporarely solution but I need a more structural one before I can deploy. Best regards, Albert Drent aducom software
#f2dcdc 754 code active 2004 Jun anonymous Shell 2004 Jun 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
#f2dcdc 744 code active 2004 May anonymous BTree 2004 May anonymous 2 2 make test seg faults on x86_64 Linux I'm running the 64 bit version of Gentoo Linux on an AMD Opteron system. Ordinarily I'd install software with "emerge " but "emerge sqlite" only gives me version 2.8.11. I downloaded the 2.8.13 source and did the usual ./configure; make; make test. The configure and make steps went OK but make test fails half way through: bind-1.99... Ok btree-1.1... Ok btree-1.1.1... Ok btree-1.2... Ok btree-1.3... Ok btree-1.4... Ok btree-1.4.1... Ok btree-1.5... Ok btree-1.6...make: *** [test] Segmentation fault The code was built with GCC 3.3.3. As sqlite is a known 'emerge' option for 64 bit Gentoo I'm guessing sqlite is known to work on 64 bit platforms? I didn't mark this as a severe error because in theory I should be able to create a statically linked executable on a 32 bit linux system and run this on the Opteron box. Haven't been successful at that yet however. _2004-May-25 04:35:32 by anonymous:_ {linebreak} It's pretty clear that sqlite has never been compiled on a 64-bit system, much less run. The test problems are fatal bugs caused by type conversions between 64-bit and 32-bit values, including truncating pointers and other sins. The fixes look quite involved.
#e8e8bd 718 new active 2004 May anonymous 2004 May anonymous 2 2 Case insensitive index ? It does not seem to be possible to create case-insensitive indices. Using UPPER() or LIKE is not as efficient and it usually requires to tweak applications in an ugly way to support case-insensitive searches. Maybe the new file format will support this ? If difficult to make it a feature, is it possible to compile sqlite to be case-insensitive for indicies (even for ones built previously); i.e. provide a #ifdef SQLITE_CASE_INSENSITIVE_INDICES
#e8e8bd 717 new active 2004 May anonymous Unknown 2004 May drh 2 2 minor fixes and port to dos attached is a diff for sqlite 2.8.13 that allows work in dos gnu environment (32 bit djgpp), even without support of long file names. it also contains minor adjacent bugfixes, in the file names handling area, and for the case of missing libreadline. please take a look, and do apply to the main source tree. i do not ask for anything, even not for personal credits. it is a very small contribution, to make your wonderful work even more popular. best regards, alex _2004-Jul-09 02:22:15 by anonymous:_ {linebreak} after feedback, mainly from hans-juergen taenzer, i have reviewed the port to dos and made better relative path support, applying to unix also. for any questions or remarks, please feel free to contact me, alex, alexbodn@012.net.il.
#f2dcdc 700 code active 2004 Apr anonymous VDBE 2004 Apr 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 *) 0x31b24
Now my basic maths (a hex 16-byte aligned number should end in 0, right?) says that somehow p.sum has become misaligned by 4 bytes. sqlite_aggregate_sum simply assigns p->pAgg to p->s.z and returns p->pAgg, which means that p->s.z is misaligned also. Further investigation makes more worrying reading: (gdb) print *context $18 = {pFunc = 0x75736572, s = {i = 0, n = 0, flags = 16, z = 0x0, r = 3.6586602629506839e-309, zShort = '\000' , "\020\000\000\000\000\000\002¡\230", '\000' }, pAgg = 0x10, isError = 0 '\000', isStep = 0 '\000', cnt = 172464}
Note that pAgg is 0x10 (!?) and s.z is 0. Something seriously unhappy going on there: I think it's likely there's some corruption going on due to some specific set of events which was being run. I'll rerun the exact scenario and try again. ---- _2004-May-03 02:27:25 by anonymous:_ {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.
#e8e8bd 524 new active 2003 Dec anonymous Unknown 2003 Dec 2 1 port of sqlite to dos with short file names i'm just appending a patch i made to work with sqlite on dos with djgpp. see the wiki for backgrounds. i hereby dedicate any and all copyright interest in this code to the public domain. i make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. i intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights this code under copyright law.
#e8e8bd 207 event active 2002 Dec anonymous Shell 2003 Dec 2 1 After installation cannot create any databases After installation of sqlite 2.7.4, use of the commandline to create a database always ends with a SQL error: database locked. The file of the database is created. I've been experiencing the same issue with 2.8.0, compiled for the Cygwin environment in Windows 95. The issue is not present if I instead compile for the MinGW environment. For my case, I've tracked it down to an issue with the behaviour of advisory locking in Cygwin (based on the fcntl POSIX function). I've patched my copy to work around the issue by clearing any existing locks on a file before attempting to acquire a new one, though I'm not too sure this is the best solution. Russell Reed (rreed@cei.net) ---- Same for me with sqlite 2.8.6. Here's my environment: $ dmesg |head Linux version 2.2.25 (root@sbgpcs22) (gcc version 2.95.4 20011002 (Debian prerelease)) \#1 SMP Mon Mar 31 19:10:06 CEST 2003 BIOS-provided physical RAM map: BIOS-e820: 0009f000 @ 00000000 (usable) BIOS-e820: terface adding patch-sets, bug tracking, and Wiki to CVS. http://www.hwaci.com/sw/cvstrac/. *: SQL Relay: A persistent database connection pooling, proxying and load balancing system with APIs for a wide range of programming languages. http://www.firstworks.com/ --> http://sqlrelay.sourceforge.net *: Zee Cookbook: A cookbook application for Sharp Zaurus PDA. hb interface adding patch-sets, bug tracking, and Wiki to CVS. http://www.hwaci.com/sw/cvstrac/. *: SQL Relay: A persistent database connection pooling, proxying and load balancing system with APIs for a wide range of programming languages. http://www.firstworks.com/ --> http://sqlrelay.sourceforge.net *: Zee Cookb iy
#e8e8bd 339 build active 2003 Jun anonymous Shell 2003 Nov 2 3 readline headers not found (because of readline/ prefix) Hi, I have GNU readline in /usr/local/include/readline : $ ls -l /usr/local/include/readline/{linebreak} total 32{linebreak} -rw-r--r-- 1 root bin 1846 Mar 6 1996 chardefs.h{linebreak} -rw-r--r-- 1 root bin 3200 Mar 6 1996 keymaps.h{linebreak} -rw-r--r-- 1 root bin 9952 Mar 6 1996 readline.h{linebreak} The shell program references the readline header-files as # include {linebreak} # include {linebreak} I believe that this is not the proper way to do it. readline.h and history.h may not be in a readline/ subdirectory. The configure script sets TARGET_READLINE_INC properly, namely to the directory where readline.h can be found (including on my machine, namely to /usr/local/include/readline). But since shell.c has the prefix readline/, it is not found. Regards, Ulrik Petersen, Denmark Here is a patch against 2.8.6: $ diff sqlite/src/shell.c sqlite-2.8.6-up-2/src/shell.c{linebreak} 40,41c40,41{linebreak} < # include {linebreak} < # include {linebreak} ---{linebreak} > # include {linebreak} > # include {linebreak} Best regards, Ulrik Petersen
#e8e8bd 483 build active 2003 Oct anonymous Shell 2003 Nov 2 3 history.h from readline library not checked for Hi, I have a system with a really old readline lying around in /usr/local/include/readline. This readline has no history.h, but src/shell.c looks for . What I am suggesting is that the configure.ac script be extended so that it checks for history.h as well as readline.h. A patch appears below. Best regards, Ulrik Petersen diff sqlite/configure.ac sqlite-2.8.6-up-2/configure.ac{linebreak} 494a495,497{linebreak} > if test "$found" = "yes"; then{linebreak} > AC_CHECK_HEADER(history.h, [found=yes], [found=no]){linebreak} > fi{linebreak} 500,501c503,507{linebreak} < TARGET_READLINE_INC="-I$dir/include"{linebreak} < break{linebreak} ---{linebreak} > AC_CHECK_FILE($dir/include/history.h, found=yes, found=no){linebreak} > if test "$found" = "yes"; then{linebreak} > TARGET_READLINE_INC="-I$dir/include"{linebreak} > break{linebreak} > fi{linebreak} 505,506c511,515{linebreak} < TARGET_READLINE_INC="-I$dir/include/readline"{linebreak} < break{linebreak} ---{linebreak} > AC_CHECK_FILE($dir/include/readline/history.h, found=yes, found=no){linebreak} > if test "$found" = "yes"; then{linebreak} > TARGET_READLINE_INC="-I$dir/include/readline"{linebreak} > break{linebreak} > fi{linebreak}
#e8e8bd 463 event active 2003 Sep anonymous 2003 Sep 2 1 list index out of bounds(1) I am using the *sqlite.dll* with "*sqlitedbu.pas*" package in *Delphi 7*. Database has only one table called "baza". _'create table baza(filename string, bin blob)';_ There is no problem when i am inserting mime encoded files into table. problem is *when i have more than 200 records*. Delphi gives me explanation : "*list index out of bounds(1)*". Same query in sqlite console works with no problems. same problem happens if i index table or when i create unique fields. query I've used is: _select filename from baza where filename like "%" order by filename;_{linebreak} *Delphi code:*{linebreak} procedure TForm1.Edit1Change(Sender: TObject);{linebreak} var t:string;{linebreak} baza:TSQLiteDB;{linebreak} i:integer;{linebreak} begin{linebreak} t:=edit1.Text;{linebreak} ListBox1.Clear;{linebreak} if (DataBaseName<>'') then begin{linebreak} baza:=TSQLiteDB.Create(nil,DataBaseName);{linebreak} baza.sql:='select filename from baza where filename like "'+t+'%" order by filename';{linebreak} baza.ExecSQL;{linebreak} baza.Open;{linebreak} if baza.RecordCount>0 then begin{linebreak} baza.First;{linebreak} while not baza.EOF do begin{linebreak} ListBox1.Items.Add(baza.Fields['filename']);{linebreak} baza.Next;{linebreak} end;{linebreak} end;{linebreak} baza.Close;{linebreak} FreeAndNil(baza);FreeAndNil(i);{linebreak} end;{linebreak} end;{linebreak}
#e8e8bd 462 event active 2003 Sep anonymous 2003 Sep 2 1 list index out of bounds(1) I am using the *sqlite.dll* with "*sqlitedbu.pas*" package in *Delphi 7*. Database has only one table called "baza". _'create table baza(filename string, bin blob)';_ There is no problem when i am inserting mime encoded files into table. problem is *when i have more than 200 records*. Delphi gives me explanation : "*list index out of bounds(1)*". Same query in sqlite console works with no problems. same problem happens if i index table or when i create unique fields. please help me to resolve this.
#e8e8bd 335 event active 2003 Jun anonymous Unknown 2003 Jun drh 2 2 ChangeCount still failing Ah, I've traced deeper in my code instead of concluding that the workaround I've implemented in version 2.8.0 is still needed. Perhaps the problem lies a bit deeper. Here's what's happening in the driver: - SQLite_Compile 'update Simpsons set Firstname = "Homer." where Lastname = "Simpson" and Firstname = "Homer" ' - SQLite_Step which returns ok - SQLiteChanges which returns 1 Now the weird thing kicks in (See also my ticket #261): - SQLite_Finalize fails with "call is out of sequence" If I perform the following ticket #335 is relevant - SQLite_Step until EOF - Don't call SQLite_Finalize (reource leaking?) Any next virtual machine will increment the SQLiteChanges with the previous SQLiteChanges, again and again. Perhaps #335 is non relevant if #261 is fixed with the procedure described above. ---- Below are snippets of log from my sqlite dbexpress driver. Every execute line is using a different virtual machine. The first time everything is ok, the second virtual machine however doesn't seem to have reset the changecount, because it returns two changes. This increments to three, four etc... ---- Execute: update Simpsons set Firstname = "Homer." where Lastname = "Simpson" and Firstname = "Homer" *Rows affected: 1* Execute: update Simpsons set Firstname = "Barney." where Lastname = "Gumbles" and Firstname = "Barney" *Rows affected: 2* _etcetera_ I am unable to reproduce this with SQLite. Can you provide a pure SQL script that generates this behavior? Are you certain the problem is in SQLite and not in the DBExpress driver?
#f2dcdc 301 code active 2003 Apr anonymous Unknown 2003 Apr 2 3 Can't acquire lock for database on Mac OS X AppleShare volume I'm using SQLite on Mac OS X 10.2.5. If I try to do a SELECT from a database that resides on an AppleShare volume (from my code or from sqlite), SQLite says that it's locked, even if no other process is using it. It appears that sqliteOsReadLock always returns SQLITE_BUSY for files on AppleShare volumes. I've temporarily solved the problem here by disabling SQLite's locking code and implementing higher-level protections in my application. You may find this link helpful: http://developer.apple.com/technotes/tn/tn2037.html _2004-Mar-22 11:21:56 by anonymous:_ {linebreak} under OSX fcntl returns ENOTSUP (45) = Operation Not Supported when trying to open a DB on AFP or SMB. Local HD is fine (HFS) as well as on USB devices HFS and UFS. Even with the recommendations from Apple's technote tn2037 the problem persists.
#e8e8bd 203 new active 2002 Dec anonymous Unknown 2002 Dec anonymous 2 1 Missing Win32 open flag if shared database In _Win32_, network and/or shared files should be opened with the _FILE_FLAG_WRITE_THROUGH_ flag in the _os.c_ file. There could be a flag when opening a database that informs the file is to be opened as shared or exclusive, and avoid locking if exclusive. I think this would improve speed considerably in "local" or exclusive databases.
#f2dcdc 2916 code active 2008 Feb anonymous 2008 Feb 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
#f2dcdc 2907 code active 2008 Jan anonymous 2008 Jan 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 2898 code active 2008 Jan anonymous 2008 Jan 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
#f2dcdc 2878 code active 2008 Jan anonymous 2008 Jan 1 1 Memory leaks with latest CVS [4693] This SQL leaks memory with CVS [4693]: CREATE TABLE x(id integer primary key, a TEXT NULL); INSERT INTO x (a) VALUES ('first'); CREATE TABLE tempx(id integer primary key, a TEXT NULL); INSERT INTO tempx (a) VALUES ('t-first'); CREATE VIEW tv1 AS SELECT x.id, tx.id FROM x JOIN tempx tx ON tx.id=x.id; One leak is caused by "CREATE TABLE tempx", a second one by "CREATE VIEW tv1". The above SQL is a digest of select7.test, select7-2.1. _2008-Jan-14 17:51:11 by anonymous:_ {linebreak} I have tested again with CVS [4711] and it does no longer show the original leaks. I therefore consider this issue fixed and I will now close this ticket. ---- _2008-Jan-14 23:56:34 by anonymous:_ {linebreak} Doing a fulltest with -MSQLITE_MEMDEUG I see reports of memory leaks. I assume these are of little or minimal interest at present because of the amount of code flux. If you do want details, please let me know (I'll recheck this ticket tomorrow I guess). ---- _2008-Jan-15 08:23:56 by anonymous:_ {linebreak} Thanks for the follow-up. I am not running the original test-suite but have have ported a great number of them to Delphi. If you could just let me know which tests caused the leaks you fixed in [4712] I'd be more than glad the port these test as well and let you know my findings. ---- _2008-Jan-19 00:56:17 by anonymous:_ {linebreak} A test from 20 minutes ago passes cleanly. This could be closed.
#f2dcdc 2897 code active 2008 Jan anonymous 2008 Jan 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 2893 code active 2008 Jan anonymous 2008 Jan 1 1 incorrect integer range tests recently a function that performs integer range tests was added to the cvs (check-in [4706]), but if i am correct there is a problem in the return value of the function in the file vdbemem.c: static i64 doubleToInt64(double r){ ... if( r<(double)minInt ){ return minInt; }else if( r>(double)maxInt ){ return minInt; <-- is this correct, shouldn't it be maxInt? }else{ return (i64)r; } } _2008-Jan-16 17:33:56 by drh:_ {linebreak} See the remarks on ticket #2280. The code duplicates the behavior of the FPU on x86. ---- _2008-Jan-16 18:21:28 by anonymous:_ {linebreak} did you mean ticket #2880? didn't read that ticket before, but since there was no comment regarding that behavior in the function it seemed (to my eyes) that it was a mistake. maybe adding a small comment in there would clarify this issue ---- _2008-Jan-16 18:39:42 by anonymous:_ {linebreak} Just because the double to int overflow behavior happens to be that way with GCC on x86, is it desirable?
#e8e8bd 2881 build active 2008 Jan anonymous 2008 Jan 1 1 Latest sqlite-3.5.4 build fail on latest Fedora 2.6.23.12-52.fc7 Two test cases fail. io-4.1... Expected: [3] Got: [2] io-4.2.1... Ok io-4.2.2... Ok io-4.2.3... Expected: [3] Got: [2] io-4.3.1... Ok Let me know how to run individual test cases and how this might be fixed. Here's how I built sqlite using latest CVS. If something is wrong here, let me know and I'll rebuild/retest. I'm building on latest Fedora fc7. Thanks. _______ net1#uname -a Linux net1.coolsurf.com 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 20:27:10 EST 2007 x86_64 x86_64 x86_64 GNU/Linux net1#build_sqlite mkdir -p /build/work/sqlite-3.5.4 cd /build/work/sqlite-3.5.4 unset CDPATH export CFLAGS='-pipe -O3 -g -DSQLITE_DISABLE_DIRSYNC=1 -Wall' rm -rf bld cvs -d :pserver:anonymous@www.sqlite.org:/sqlite -r update . mkdir bld cd bld ../configure --prefix=/common/pkgs/sqlite-3.5.4 --enable-tcl --with-tcl=/usr/lib64 --enable-threadsafe --enable-threads-override-locks make groupadd vuser || /bin/true useradd -M -g vuser -d /vhost/davidfavor.com/users/david -s /bin/zsh david || /bin/true useradd -M -g vuser -d /vhost/livefeast.com/users/yemiah -s /bin/zsh yemiah || /bin/true chown david:vuser -R .. su -c "make test" david _2008-Jan-11 17:18:52 by anonymous:_ {linebreak} Same tests still fail with CVS of today around 11AM CST. ---- _2008-Jan-11 17:41:55 by drh:_ {linebreak} FWIW, both those test cases pass on SuSE 10.1. I do not understand why they are failing on Fedora. But in any event, the tests in question are verifying logic that implements an optimization that is not used on Fedora, ever. So the failures are of no consequence. If those are the only two tests that fail, then you can safely use the build for whatever it is you are trying to do. ---- _2008-Jan-11 19:16:19 by anonymous:_ {linebreak} Failures when 'make fulltest' built with CFLAGS of '-pipe -O3 -g -Wall -DSQLITE_DISABLE_DIRSYNC=1 -DSQLITE_MEMDEBUG' exclusive-malloc-1.transient.746...make: *** [fulltest] Segmentation fault Failures when 'make fulltest' built with CFLAGS of '-pipe -O3 -g -Wall -DSQLITE_DISABLE_DIRSYNC=1' Skipping malloc tests: not compiled with -DSQLITE_MEMDEBUG... 6 errors out of 61998 tests Failures on these tests: exclusive-ioerr-2.280.4 exclusive-ioerr-2.281.4 exclusive-ioerr-2.282.4 incrvacuum-ioerr-1.31.4 io-4.1 io-4.2.3 All memory allocations freed - no leaks Maximum memory usage: 14376554 bytes Pre 3.5.x builds work fine on Fedora. If you're open to debugging all these, I'd like to go through and resolve all these one by one, so Fedora has a clean build/fulltest. Please let me know how to run each test individually and I'll try to figure out the problem with each. Thanks.
#f2dcdc 2874 code active 2008 Jan anonymous 2008 Jan 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 2873 code active 2008 Jan anonymous 2008 Jan 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 2866 build active 2008 Jan anonymous 2008 Jan 1 3 Problems building Windows native in cygwin/mingw environment Trying to build Windows native version using the Cygwin build environment. $ gcc -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) $ $ CFLAGS=-mno-cygwin ./configure --disable-tcl --enable-threadsafe $ make A) The make appears to build sqlite3.exe just fine, without errors or warnings. This binary does work from cmd.exe, BUT not from within the bash cygwin shell for some reason, unlike other Windows native binaries I've built. Next... $ make install B) The cc sqlite3.c -o sqlite3 fails to rebuild sqlite3.exe correctly with the -mno-cygwin option. The output follows: rm -rf tsrc mkdir -p tsrc cp ./src/alter.c ./src/analyze.c ./src/attach.c ./src/auth.c ./src/btmutex.c ./src/btree.c ./src/btree.h ./src/build.c ./src/callback.c ./src/complete.c ./src/date.c ./src/delete.c ./src/expr.c ./src/func.c ./src/hash.c ./src/hash.h ./src/insert.c ./src/journal.c ./src/legacy.c ./src/loadext.c ./src/main.c ./src/malloc.c ./src/mem1.c ./src/mem2.c ./src/mem3.c ./src/mutex.c ./src/mutex_os2.c ./src/mutex_unix.c ./src/mutex_w32.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pager.h ./src/parse.y ./src/pragma.c ./src/prepare.c ./src/printf.c ./src/random.c ./src/select.c ./src/shell.c ./src/sqlite.h.in ./src/sqliteInt.h ./src/table.c ./src/tclsqlite.c ./src/tokenize.c ./src/trigger.c ./src/utf.c ./src/update.c ./src/util.c ./src/vacuum.c ./src/vdbe.c ./src/vdbe.h ./src/vdbeapi.c ./src/vdbeaux.c ./src/vdbeblob.c ./src/vdbefifo.c ./src/vdbemem.c ./src/vdbeInt.h ./src/vtab.c ./src/where.c ./ext/fts1/fts1.c ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.c ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_porter.c ./ext/fts1/fts1_tokenizer.h ./ext/fts1/fts1_tokenizer1.c sqlite3.h ./src/btree.h ./src/btreeInt.h ./src/hash.h ./src/sqliteLimit.h ./src/mutex.h opcodes.h ./src/os.h ./src/os_common.h ./src/sqlite3ext.h ./src/sqliteInt.h ./src/vdbe.h parse.h ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_tokenizer.h ./src/vdbeInt.h tsrc cp: warning: source file `./src/btree.h' specified more than once cp: warning: source file `./src/hash.h' specified more than once cp: warning: source file `./src/sqliteInt.h' specified more than once cp: warning: source file `./src/vdbe.h' specified more than once cp: warning: source file `./ext/fts1/fts1.h' specified more than once cp: warning: source file `./ext/fts1/fts1_hash.h' specified more than once cp: warning: source file `./ext/fts1/fts1_tokenizer.h' specified more than once cp: warning: source file `./src/vdbeInt.h' specified more than once rm tsrc/sqlite.h.in tsrc/parse.y cp parse.c opcodes.c keywordhash.h tsrc tclsh ./tool/mksqlite3c.tcl cc sqlite3.c -o sqlite3 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab): undefined reference to `_WinMain@16' collect2: ld returned 1 exit status make: *** [sqlite3] Error 1 $
#f2dcdc 2865 code active 2007 Dec anonymous 2007 Dec 1 2 FTS3 does not build with amalgamation in CVS Grab the latest CVS sources, then run: ./configure make sqlite3.c grep sqlite3Fts3Init sqlite3.c extern int sqlite3Fts3Init(sqlite3*); rc = sqlite3Fts3Init(db); If you compile sqlite3.c with -DSQLITE_ENABLE_FTS3, then sqlite3Fts3Init is unresolved. For some reason, sqlite3Fts3Init and fts3.c was not included in the sqlite3.c amalg. It used to work correctly in 3.5.4. _2007-Dec-30 18:17:57 by anonymous:_ {linebreak} Nevermind, "make sqlite3.c" has never built with the fts3 sources in 3.5.4 or before. You have to run ext/fts3/mkfts3amal.tcl ---- _2007-Dec-30 18:20:56 by anonymous:_ {linebreak} It seems that the sqlite3+fts3 amalg can only be built from main.mk, not Makefile.
#f2dcdc 2508 code active 2007 Jul anonymous 2007 Dec 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; }
#e8e8bd 916 new active 2004 Sep anonymous Unknown 2007 Dec 1 1 No delete notification for INSERT OR REPLACE It would be nice if the "ON DELETE" trigger is called for the row substituted with a new one during REPLACE. Or, even better, one could add the OLD statement for the "ON INSERT" trigger and set it to point to the same row as NEW if a new row is inserted or to the deleting row if replace occurs. Thanks. _2007-Dec-17 21:36:40 by anonymous:_ {linebreak} I have the same problem. My solution would be to stick with the documentation of the ON REPLACE algorithm: "When a UNIQUE constraint violation occurs, the pre-existing rows that are causing the constraint violation are removed prior to inserting or updating the current row". That is, to call ON DELETE trigger whenever rows are removed. Thank you, and keep going, you do wonderful job anyway.
#f2dcdc 2842 code active 2007 Dec anonymous 2007 Dec 1 1 .import does not recongnise NULL values .import function fails to see NULL values in csv files as NULL values...instead they are treated as the string "NULL". This is with .mode list and separator , But behaves similarly for .mode csv Also if one outputs a table with NULL values to a file, then re-imports that file, again .import does not recognise the values as NULL, but as "NULL". Everything here also applies to empty strings in files, e.g. instead of "NULL" using nothing... This is a showstopper for us since we want to import a large amount of data with many tables containing NULL values. I can't see any valid reason for .import not to recognise the same syntax as the command line. Note that something like: sqlite3 my.db insert into MY_TABLE values (1,"foo","bar",NULL) ..works fine. It is just .import that appears to be broken. _2007-Dec-14 16:39:51 by rdc:_ {linebreak} .import only inserts string values into database tables. If your column has a declared type that changes the columns affinity to numeric or integer, then those strings will be converted to numeric values by the SQLIte library. The workaround is to simply insert a unique string where ever you want a NULL value, and then run an update that replaces those strings with real NULL values. If you inserted the string 'NULL' then do this after the .import update t set field = null where field = 'NULL'; You will have to repeat this for each field in your table that might contain the 'NULL' string.
#e8e8bd 2841 todo active 2007 Dec anonymous 2007 Dec 1 1 The sqlite mailing list has become overrun by trolls The sqlite mailing list is very useful. The S/N is at times a little high but nonetheless quite manageable. Recently (see the DeviceSQL thread) it got really bad. Would moderation be unacceptable during these periods of time where people feel the need to protect their ego's? The sqlite mailing list is primarily about sqlite (well, and lemon), not a marketing vector for other products? Surely they have their own lists and resources for that?
#e8e8bd 2813 build active 2007 Nov anonymous 2007 Nov 1 1 compile error on Windows CE environment: visual c++ 2005 window ce 6.0 customize sdk sqlite-amalgamation-3_5_3 I get error: Error 27 error C2040: 'localtime' : 'tm *(const time_t *)' differs in levels of indirection from 'int ()' d:\SubProjects\Sqlite\sqlite3.c 18574 but if I add code in line 7095: struct tm *__cdecl localtime(const time_t *t); then Success!
#f2dcdc 2809 code active 2007 Nov anonymous 2007 Nov 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 2810 code active 2007 Nov anonymous 2007 Nov 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|
#f2dcdc 2791 code active 2007 Nov anonymous 2007 Nov 1 1 Allow building FTS[123] as part of sqlite library with configure See attached patch.
#f2dcdc 2770 code active 2007 Nov anonymous 2007 Nov 1 1 Problem with BLOB in 3.5.x ? After I've switched from 3.3.18 to 3.5.2, selecting from table which contains BLOB LONGER THAN ABOUT 990 BYTES returns error "SQL logic error or missing database" after call to _sqlite3_step(). I'm using preprocessed sources downloaded from here. DEBUG build of preprocessed sources works correctly, problem is only in RELEASE build. I'm using VC6.0 to compile. Any idea what could be wrong? Thank you! Can you try to reproduce this with the sqlite shell tool? Thanks. Large blobs work for me with both release and debug builds (not msvc though, gcc/linux). ---- _2007-Nov-12 18:41:37 by anonymous:_ {linebreak} sqlite3.exe provided here works with the database. Problem is only with release build (static library linked into test application). Here is test app which exits with "Error 1" in release build: int main(int argc, char* argv[]) { int rc; sqlite3* db; sqlite3_stmt* stmt; rc = sqlite3_open("n2.db3", &db); rc = sqlite3_prepare(db, "CREATE TABLE [ttt] ([bbb] BLOB)", -1, &stmt, 0 ); rc = sqlite3_step(stmt); rc = sqlite3_reset(stmt); char text[10000],query[20000]; strnset(text,'a',sizeof(text)-1); sprintf(query,"insert into [ttt] values (?)"); rc = sqlite3_prepare(db, query, -1, &stmt, 0 ); rc = sqlite3_bind_blob(stmt,1,text,sizeof(text), SQLITE_TRANSIENT); rc = sqlite3_step(stmt); rc = sqlite3_reset(stmt); rc = sqlite3_prepare(db, "select * from ttt", -1, &stmt, 0 ); rc = sqlite3_step(stmt); if (rc == SQLITE_ROW) { printf("%s: OK",sqlite3_column_text(stmt,1)); } else if (rc == SQLITE_DONE) { printf("DONE"); } else { printf("Error %d",rc); } return 0; } ---- _2007-Nov-12 18:56:24 by drh:_ {linebreak} You should be using sqlite3_finalize() instead of sqlite3_reset(). You are leaking memory. Also, you should use sqlite3_prepare_v2() to avoid problems with changing schemas. But even without those fixes, I cannot reproduce the problem on Linux. ---- _2007-Nov-12 19:39:31 by anonymous:_ {linebreak} Suggested fixes didn't help. I've tried to debug it. It fails in btree.c, line 3056: if( offset+amt > nKey+pCur->info.nData ){ /* Trying to read or write past the end of the data is an error */ return SQLITE_ERROR; } there seems to be different values in release mode. My debugger does not show values of variables in release mode, so I can be wrong, but it seems in release offset is 5 and in debug it is 4. There can be something wrong with compilation, I'll try to figure this out tomorrow. BTW compilation of static libraty in VC6.0 gives 185 warnings. I don't know if it is ok, it haven't caused problems in older sqlite ---- _2007-Nov-13 08:47:28 by anonymous:_ {linebreak} I've turned off "Maximize Speed" option - this is causing the problem. No optimizations and optimize for size seems to be working. But it still makes me nervous :(( I really don't need corrupted database and now I hope it won't slow down too much. Unfortunately old library does not implement replace function so I don't want to switch back. This could be warning to others, I'm using VC++ 6.0 SP 6. Thank you for your time. ---- _2007-Nov-22 17:20:31 by anonymous:_ {linebreak} I have exactly the same problem here (win XP, vc6 SP2) when I link against my sqlite static or dynamic library in release. I have also used boundschecker to check sqlite, and it detects many dangling pointers ! But the strange thing is that I cannot find why these pointers are dangling, here an example: In prepare.c@188 pTab = sqlite3FindTable(db, zMasterName, db->aDb[iDb].zName); Boundchecker say that zMasterName is a dangling pointer, previously released here: in build.c@711: void sqlite3StartTable( Parse *pParse, /* Parser context */ Token *pName1, /* First part of the name of the table or view */ Token *pName2, /* Second part of the name of the table or view */ int isTemp, /* True if this is a TEMP table */ int isView, /* True if this is a VIEW */ int isVirtual, /* True if this is a VIRTUAL table */ int noErr /* Do nothing if table already exists */ ){ } It does not make sens for me, maybe it a false positive from boundchecker, but it is weird. I don't know if these "errors" are related to the "blob" bug in release mode. I will try to debug these error with some "printf" in release mode. Note: The provided dll (the one from the sqlite site) does not have this "bug". ---- _2007-Nov-22 18:27:35 by anonymous:_ {linebreak} More info: It seems that there is a bug in the VC6 (SP6) compiler. In btree.c, line 3056: if( offset+amt > nKey+pCur->info.nData ){ /* Trying to read or write past the end of the data is an error */ return SQLITE_ERROR; } After adding some printf around, It seems that the "speed optimization" compilation flag of VC6 changes the code order in a way that the offset variable is miss incremented !! Two remarks: *: I've traced the calling function, sqlite3BtreeData, and the it call accessPayload with the good offset value *: VC6 produces an internal error: "fatal error C1001: INTERNAL COMPILER ERROR" in the accessPayload function, if I try to access the offset value before this line: aPayload = pCur->info.pCell + pCur->info.nHeader; A dirty workaround could be to change the code order or the local var usage. I'm trying ....
#f2dcdc 2766 code active 2007 Nov drh 2007 Nov 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....
#e8e8bd 2756 new active 2007 Nov anonymous 2007 Nov 1 1 allow vacuum to change pragma setting instead of using existing ones we've got databases created with page_size of 1k, and we'd like to change that setting to 4k. vacuum creates a temporary db, attach it to the current connection, creates the tables (based on what's in the old db), and then selects from the old db and inserts into the new one. vacuum does exactly what we need (creating a new db from an old one), but it re-uses the existing pragmas for page size, auto vacuum and reserved page size. from sqlite.c, see sqlite3RunVacuum() sqlite3BtreeSetPageSize(pTemp, sqlite3BtreeGetPageSize(pMain), sqlite3BtreeGetReserve(pMain)); dr hipp points out that the the operands to vacuum are unused. from sqlite.c: sqlite3VdbeAddOp(v, OP_Vacuum, 0, 0); one solution would be to allow the user to specify the page size, reserve page size, and autovacuum as optional params to vacuum. he had an idea of using the signedness of the first operand to represent the autovacuum setting (since after a table is created, you can change the setting from auto to incremental, but you can't change it from none to auto (or none to incremental)
#f2dcdc 2715 code active 2007 Oct anonymous 2007 Oct 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.
#e8e8bd 2729 doc active 2007 Oct anonymous 2007 Oct 1 1 Lemon: %fallback, %wildcard, and @X uncodumented I noticed that the lemon documentation does not mention the %fallback and %wildcard directives. Both are in the code and are apparently doing useful work in SQLite's parse.y. Can other users benefit from them as well? The symbol @X is also undocumented. From a source code comment I read that it "If the argument is of the form @X then substituted the token number of X, not the value of X". A short documentation example would help to understand where and how it can be useful to apply this syntax. Are there other nice but undocumented Lemon goodies lacking documentation?
#f2dcdc 2725 code active 2007 Oct anonymous 2007 Oct 1 1 memory leak in sqlite3_open_v2() when it fails only happens with flags = SQLITE_OPEN_READWRITE; and when res = sqlite3_open_v2(sourcename, &conn, flags, NULL); seems to leak 674 bytes per call _2007-Oct-15 07:07:07 by danielk1977:_ {linebreak} Are you calling sqlite3_close(conn) after the error occurs? All calls to sqlite3_open_v2() need to be matched by a call to sqlite3_close(), even if an error occurs.
#f2dcdc 2684 code active 2007 Oct anonymous 2007 Oct 1 1 Accessing sqlite from an NT service will lock the complete databse. Accessing sqlite from a NT service (application 1) will lock the complete database. Any other process trying to open an sqlite db (application 2) will get error "80004005 unable to lock database" If application 1 runs as normal application, started by local user, this problem doesnt occur and both applications can open the db. _2007-Oct-02 15:48:05 by anonymous:_ {linebreak} SQLite has no knowledge of Windows services. How do you propose to work around this Windows anachronism? ---- _2007-Oct-02 17:20:38 by anonymous:_ {linebreak} Suggesion: Try running the service in the same account as the other program that needs to access the database. Anachronism? Service is just another word for daemon. -knu- ---- _2007-Oct-02 17:33:56 by anonymous:_ {linebreak} Re: Anachronism, the OP suggested there was something fundamentally different about file access using a service. You've pointed out that it's just a file permissions issue. ---- _2007-Oct-05 14:45:07 by drh:_ {linebreak} Two points: 1: The error message "80004005 unable to lock database" is not generated by SQLite. There must be some middleware someplace that is producing this message. The problem might be in that middleware and not in SQLite. 2: None of the SQLite developers run windows. Consequently any fixes for this problem will need to come from the community. Please append patches to this ticket if you find a fix. Or close the ticket if you discover that the problem is outside of SQLite.
#f2dcdc 2664 code active 2007 Sep danielk1977 2007 Sep 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
#f2dcdc 2652 code active 2007 Sep drh 2007 Sep 1 1 Aggregate function cannot be used from within a subquery The following SQL fails: CREATE TABLE t1(x,y); INSERT INTO t1 VALUES(1,2); CREATE TABLE t2(z); INSERT INTO t2 VALUES(1); SELECT (SELECT y FROM t1 WHERE x=min(z)) FROM t2; Problem reported on the mailing list. _2007-Sep-23 16:01:09 by anonymous:_ {linebreak} Your syntax appears to be incorrect.{linebreak} SQLite v3.4.2 CREATE TABLE t1(x,y); CREATE TABLE t2(z); INSERT INTO t1 VALUES(1,21); INSERT INTO t1 VALUES(2,22); INSERT INTO t1 VALUES(3,23); INSERT INTO t2 VALUES(3); INSERT INTO t2 VALUES(2); INSERT INTO t2 VALUES(1); What you wanted to do: SELECT y FROM t1 WHERE x=(SELECT min(z) FROM t2); 21 -- works as expected What you did: SELECT (SELECT y FROM t1 WHERE x=min(z)) FROM t2; SQL error near line []: misuse of aggregate function min()
#f2dcdc 2580 code active 2007 Aug anonymous 2007 Aug anonymous 1 2 Can't open a query if text to search is Greek for example: SELECT * FROM mytable WHERE mycolumn LIKE '%some greek text%' I get wrong results, using the 3.4.2 version. No problem instead using other earlier version. I tested only in Windows.
#e8e8bd 2555 new active 2007 Aug anonymous 2007 Aug 1 1 FTS index without original text Is it possible to build FTS index without storing original text? I want to use fts index without features of snippets etc. I just want to find ID of the record not the content of indexed phrase. I suppose that the table myname_content stores this content. I have tried to update all columns of myname_content and set its values to “xyz” (without one column in which I store ID of the record). After this operation FTS search works good, but unfortunately the table isn’t smaller (I cant’t use vacuum on FTS tables). Is there any other way to have pure text indexes without source level changes?
#f2dcdc 2545 code active 2007 Jul anonymous 2007 Jul 1 4 Group by returns table name with field name imaginate a table: create table test (
id INTEGER PRIMARY KEY,
name varchar(50) not null,
age integer not null
);
Then: insert into test (name,age) values ('foo',22);
insert into test (name,age) values ('foo',23);
insert into test (name,age) values ('bar',22);
insert into test (name,age) values ('bar',35);
insert into test (name,age) values ('bar',72);
Now try this; sqlite> .headers on
sqlite> select test.name, test.age from test order by name;
name|age
bar|22
bar|35
bar|72
foo|22
foo|23
sqlite> select test.name, test.age from test group by name;
test.name|test.age
bar|72
foo|23
You see ? if i use "GROUP BY", the field name contains tablename. Because i use "SELECT test.name" and not "SELECT name". If i set an alias, i get alias, that's ok. The trouble appears to be very high on Copix (http://wwW.copix.org). We create some DAO (Data Access Objects) automatically. The "groupBy" method doesn't works with SQLite... Is this normal ? Mysql, PostgreSql, Oracle... doesn't need to create alias. _2007-Jul-31 15:54:52 by anonymous:_ {linebreak} There's probably 4 other tickets reporting this. I don't think it will get fixed. The workaround is to use aliases (AS "whatever") for the selected columns. ---- _2007-Jul-31 23:02:19 by anonymous:_ {linebreak} Ok, we have created a special support for SQLite. PS: I love this database :) Simple, nice, usefull, quick and easy Regards
#f2dcdc 2543 code active 2007 Jul anonymous 2007 Jul 1 1 Chinese charset not support?? when i create a table. the table name is " " (chinese) after this "alter table add column aaa text null" error why??/ thank you
#e8e8bd 2469 build active 2007 Jun anonymous 2007 Jul 1 1 test fails on Solaris I have a problem running the test suite on Solaris 9. Build was done using gcc 4.2.0. The build completes without error but many tests fail. I've created my own minimal test that exhibits the problem: set testdir [file dirname $argv0] source $testdir/tester.tcl db close file delete -force test.db test.db-journal sqlite db test.db do_test tdb-1 { execsql { PRAGMA auto_vacuum = 1; BEGIN; CREATE TABLE t1(a, b); } execsql { COMMIT; } } {} integrity_check tdb-2 finish_test
When running this test I get the following output: tdb-1... Ok tdb-2... Expected: [ok] Got: [{*** in database main *** List of tree roots: 2nd reference to page 1 Page 3 is never used}] Thread-specific data deallocated properly 1 errors out of 3 tests Failures on these tests: tdb-2
This error happens on lots of, but not all, tests. I'm happy to do whatever is necessary to help debug this. Thanks, Tim. _2007-Jun-27 10:44:14 by anonymous:_ {linebreak} Further to this, it appears to be related to gcc 4.2.0. It works fine with gcc 3.4.6. ---- _2007-Jun-28 09:54:35 by anonymous:_ {linebreak} Further more, it doesn't appear to be specific to Solaris. The same problem occurs on Linux with gcc 4.2.0. So I guess the subject of this ticket should be changed to "build/test problems with gcc 4.2.0". This is probably a significant problem - the build completes find but the resultant code is broken. People may not notice this until it's too late. ---- _2007-Jun-28 12:24:05 by drh:_ {linebreak} I installed gcc 4.2.0 on my SuSE linux i686 desktop and built test harnesses under three different configurations: gcc420 -g -O0 -Wall -fstrict-aliasing gcc420 -g -O3 -Wall gcc420 -g -O3 -fstrict-aliasing -fomit-frame-pointer The first two configurations used separate source files. The third configuration was built using the amalgamation. I ran the "quick" test under all configurations. All tests ran to completion with no errors. ---- _2007-Jun-28 13:22:20 by anonymous:_ {linebreak} Two ideas: 1. Compile with gcc 4.2.0 using -O0 instead of -O2 and see what happens. Disable any other optimizations you may have. 2. Run truss with full read/write buffer display on the gcc 3.4.6 compiled testfixture running your simple test case and compare its output to the gcc 4.2.0 compiled test case. ---- _2007-Jul-01 19:00:40 by anonymous:_ {linebreak} I've done tests with optimisation, and this appears to tickle the problem. With no optimisation, -O, -O0, -O1 and -03 it works. With -O2 and -Os it's broken. I was compiling with -O2 when I submitted the initial report. Tim. ---- _2007-Jul-01 19:54:54 by drh:_ {linebreak} I can reproduce the problem now on Linux when compiling as follows: gcc420 -g -O2 -Wall ---- _2007-Jul-01 21:50:42 by drh:_ {linebreak} This appears to be a bug in GCC 4.3.0. A work-around is to compile with the -fno-tree-vrp option. GCC appears to miscompile a single loop within the logic that implements the integrity_check PRAGMA. The code that gets miscompiled is in the file vdbe.c (lines numbers added): 4308 for(j=0; j RCS file: /sqlite/sqlite/src/vdbe.c,v retrieving revision 1.636 diff -u -3 -p -r1.636 vdbe.c --- src/vdbe.c 1 Jul 2007 21:18:40 -0000 1.636 +++ src/vdbe.c 21 Jul 2007 19:10:13 -0000 @@ -4306,7 +4306,8 @@ case OP_IntegrityCk: { pnErr = &p->aMem[j]; assert( (pnErr->flags & MEM_Int)!=0 ); for(j=0; ju.i; } aRoot[j] = 0; popStack(&pTos, nRoot);