Re: [sqlite] Sqlite 3.3.7 intel compiler warnings
I know. I checked them all and at least they are dangerous and probably not obvious. I think the one in os_win.c is really a bug unless the intention were to always return OK. - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Sqlite 3.3.7 intel compiler warnings
I already filtered out all the "common" warnings but these: build.c(1969): remark #1599: declaration hides variable "v" (declared at line 1883) Vdbe *v = sqlite3GetVdbe(pParse); ^ expr.c(1520): remark #1599: declaration hides variable "op" (declared at line 1489) int op = (pTab && IsVirtual(pTab)) ? OP_VColumn : OP_Column; ^ expr.c(1530): remark #1599: declaration hides variable "op" (declared at line 1489) int op = (pTab && IsVirtual(pTab)) ? OP_VRowid : OP_Rowid; ^ I think this one is a bug: os_win.c(840): remark #1599: declaration hides variable "rc" (declared at line 838) int rc, cnt = 0; ^ vtab.c(326): remark #1599: declaration hides variable "zModule" (declared at line 316) const char *zModule = pTab->azModuleArg[0]; ^ where.c(1043): remark #1599: declaration hides variable "pTerm" (declared at line 1032) WhereTerm *pTerm; ^ where.c(2040): remark #1599: declaration hides variable "j" (declared at line 2002) int j; ^ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Cannot compile with SQLITE_OMIT_VIRTUALTABLE
Oops. Ok, I got it. Thanks. - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Cannot compile with SQLITE_OMIT_VIRTUALTABLE
Lattest cvs sqlite version: If SQLITE_OMIT_VIRTUALTABLE is defined linker complains about: parse.obj : error unresolved external symbol _sqlite3VtabArgExtend in function _yy_reduce parse.obj : error unresolved external symbol _sqlite3VtabArgInit in function _yy_reduce parse.obj : error unresolved external symbol _sqlite3VtabBeginParse in function _yy_reduce parse.obj : error unresolved external symbol _sqlite3VtabFinishParse in function _yy_reduce These functions are declared in sqliteint.h line 1863-1866. These functions are implemented in vtab.c but enclosed in: #ifndef SQLITE_OMIT_VIRTUALTABLE ... #endif And of course, these functions are used in function reduce without any SQLITE_OMIT_VIRTUALTABLE check. Hope this helps. - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] future of sqlite
Is there any list of future enhancements, new features, etc on sqlite we can drool for?
[sqlite] Check in 3056
I think there is a logic error in check in 3056:
void *sqlite3Realloc(void *p, int n){
void *np = 0;
if( !sqlite3MallocFailed() ){
#ifndef SQLITE_ENABLE_MEMORY_MANAGEMENT
int oldsize = OSSIZEOF(p);
#endif
while( (np = OSREALLOC(p, n))==0 && sqlite3_release_memory(n) );
if( !np || handleSoftLimit(OSSIZEOF(np) - oldsize) ){
OSFREE(np);
sqlite3FailedMalloc();
OSMALLOC_FAILED();
}
}
return np;
}
Variable oldsize in line 595 is not initialized if macro
SQLITE_ENABLE_MEMORY_MANAGEMENT is set.
[sqlite] Intel compiler warnings with 3.3.3
No bugs, just "benign" warnings. btree.c .\Sqlite\v3\btree.c(432): remark #1418: external definition with no prior declaration int sqlite3_btree_trace=0; /* True to enable tracing */ ^ This variable is only used here and in test3.c. I guess it should be enclosed between the #if SQLITE_TEST directive and modify the test3.c to take that into account. Same with sqlite3_os_trace in os_common.h. And sqlite3_opentemp_count? .\Sqlite\v3\btree.c(6535): remark #111: statement is unreachable return sqlite3pager_sync(pBt->pPager, zMaster, 0); ^ I think the second sqlite3pager_sync call needs to be enclosed in the #else directive. (no harm). os_win.c .\Sqlite\v3\os_win.c(99): remark #1418: external definition with no prior declaration. Can be made static. int sqlite3_os_type = 0; ^
[sqlite] Intel compiler warnings with 3.3.3
I will point out only some kind of warnings I saw (i.e. not signed vs
unsigned) using the Intel Compiler:
os_win.c
.\Sqlite\v3\os_win.c(1482): warning #300: const variable "zeroData" requires
an initializer
static const ThreadData zeroData;
^
the patch was done in os_unix but not here.
vdbe.c
.\Sqlite\v3\vdbe.c(3818): remark #1599: declaration hides variable "rc"
(declared at line 396)
int res, rc;
^
shell.c
.\Sqlite\v3\shell.c(250): remark #1418: external definition with no prior
declaration. Can be made static.
char *modeDescr[MODE_NUM_OF] = {
^
.\Sqlite\v3\shell.c(914): remark #1599: declaration hides variable "i"
(declared at line 850)
int i;
^
.\Sqlite\v3\shell.c(1023): remark #1599: declaration hides variable "rc"
(declared at line 853)
int rc; /* Result code */
^
.\Sqlite\v3\shell.c(1026): remark #1599: declaration hides variable "i"
(declared at line 850)
int i, j; /* Loop counters */
^
.\Sqlite\v3\shell.c(1029): remark #1599: declaration hides parameter "zLine"
(declared at line 849)
char *zLine;/* A single line of input from the file */
^
.\Sqlite\v3\shell.c(1232): remark #1599: declaration hides variable "i"
(declared at line 850)
int i;
^
.\Sqlite\v3\shell.c(1292): remark #1599: declaration hides variable "i"
(declared at line 850)
int i;
^
.\Sqlite\v3\shell.c(1314): remark #1599: declaration hides variable "rc"
(declared at line 853)
int nRow, rc;
^
.\Sqlite\v3\shell.c(1346): remark #1599: declaration hides variable "i"
(declared at line 850)
int i, j;
^
.\Sqlite\v3\shell.c(1456): remark #1599: declaration hides variable "rc"
(declared at line 1447)
int rc = do_meta_command(zLine, p);
^
.\Sqlite\v3\shell.c(1621): remark #1418: external definition with no prior
declaration. Can be made static.
void main_init(struct callback_data *data) {
^
.\Sqlite\v3\shell.c(1693): warning #266: function declared implicitly. This
"no include header" was always missing (since version 2.x).
if( access(data.zDbFilename, 0)==0 ){
^
Also:
main.c
.\Sqlite\v3\main.c(32): remark #1418: external definition with no prior
declaration
const char rcsid3[] = "@(#) \044Id: SQLite version " SQLITE_VERSION " $";
^
This rcsid3 is not found/used anywhere else.
.\Sqlite\v3\main.c(33):
const char sqlite3_version[] = SQLITE_VERSION;
this is only used in func.c, but it could use sqlite3_libversion. Why
publish both of them? I would leave the sqlite3_version[] static in main.c
[sqlite] Intel compiler warnings with 3.3.2
Since these are nots a bug I will post them here my findings with 3.3.2 with
Intel compiler (one of the best and fast compiled code I've seen) under
Windows:
attach.c
.\Sqlite\v3\attach.c(36): remark #1418: external definition with no prior
declaration
int resolveAttachExpr(NameContext *pName, Expr *pExpr)
This means, this function can be made static (static function addresses
usually occupy a word instead of a sizeof (void*), in win32)
.\Sqlite\v3\attach.c(179): remark #1599: declaration hides variable "i"
(declared at line 65)
int i = db->nDb - 1;
build.c
.\Sqlite\v3\build.c(3160): remark #1599: declaration hides variable "z"
(declared at line 3139)
char *z = sqliteStrNDup((const char *)pName1->z, pName1->n);
date.c
.\Sqlite\v3\date.c(508): remark #1572: floating-point equality and
inequality comparisons are unreliable
&& (n=r)==r && n>=0 && r<7 ){
^
.\Sqlite\v3\date.c(508): remark #1572: floating-point equality and
inequality comparisons are unreliable
&& (n=r)==r && n>=0 && r<7 ){
^
.\Sqlite\v3\date.c(821): remark #1599: declaration hides variable "n"
(declared at line 758)
int n; /* Number of days since 1st day of year */
^
delete.c
.\Sqlite\v3\delete.c(213): remark #1599: declaration hides variable "addr"
(declared at line 94)
int addr;
^
expr.c
.\Sqlite\v3\expr.c(921): remark #1599: declaration hides variable "j"
(declared at line 820)
int j;
^
.\Sqlite\v3\expr.c(1080): remark #593: variable "pSrcList" was set but never
used
SrcList *pSrcList;
^
Missing #ifndef NDEBUG around the variable.
.\Sqlite\v3\expr.c(1383): remark #1599: declaration hides variable "i"
(declared at line 1363)
int i;
^
.\Sqlite\v3\expr.c(1551): remark #1599: declaration hides variable "op"
(declared at line 1463)
int aff, op;
^
insert.c
.\Sqlite\v3\insert.c(300): remark #1599: declaration hides variable "base"
(declared at line 203)
int base = sqlite3VdbeCurrentAddr(v);
^
.\Sqlite\v3\insert.c(683): remark #1599: declaration hides variable "base"
(declared at line 203)
int base = sqlite3VdbeCurrentAddr(v);
^
os_win.c
.\Sqlite\v3\os_win.c(517): remark #1419: external declaration in primary
source file
int allocateWinFile(winFile *pInit, OsFile **pId);
This means, this function can be made static.
.\Sqlite\v3\os_win.c(1482): warning #300: const variable "zeroData" requires
an initializer
static const ThreadData zeroData;
This is tricky, according to C, const variables must be initialized, but
static variables are initiated to zeroes.
pager.c
.\Sqlite\v3\pager.c(1274): remark #279: controlling expression is constant
while( 1 ){
^
These forms can be translated with not penalty in speed-code into for (;;).
.\Sqlite\v3\pager.c(1447): remark #1599: declaration hides variable "nRec"
(declared at line 1377)
u32 nRec;
^
.\Sqlite\v3\pager.c(2559): remark #1599: declaration hides variable "rc"
(declared at line 2527)
int rc;
^
.\Sqlite\v3\pager.c(2683): remark #1599: declaration hides variable "rc"
(declared at line 2527)
int rc;
^
printf.c
.\Sqlite\v3\printf.c(599): remark #1599: declaration hides variable "c"
(declared at line 212)
int i, j, n, c, isnull;
^
.\Sqlite\v3\printf.c(601): remark #1599: declaration hides parameter "arg"
(declared at line 207)
char *arg = va_arg(ap,char*);
^
select.c
.\Sqlite\v3\select.c(24): remark #1418: external definition with no prior
declaration
void clearSelect(Select *p){
^
This means, this function can be made static.
.\Sqlite\v3\select.c(560): remark #1599: declaration hides parameter "aff"
(declared at line 457)
char aff = (iParm>>16)&0xFF;
^
.\Sqlite\v3\select.c(1212): remark #1599: declaration hides variable "pTab"
(declared at line 1081)
Table *pTab = pFrom->pTab;
^
.\Sqlite\v3\select.c(1227): remark #1599: declaration hides variable "pLeft"
(declared at line 1223)
struct SrcList_item *pLeft = >a[i-1];
^
vdbe.c
.\Sqlite\v3\vdbe.c(2974): remark #1599: declaration hides variable "rc"
(declared at line 396)
int res, rc;
^
.\Sqlite\v3\vdbe.c(3811): remark #1599: declaration hides variable "rc"
(declared at line 396)
int res, rc;
^
where.c
.\Sqlite\v3\where.c(427): remark #1599: declaration hides variable "k"
(declared at line 416)
int k;
^
.\Sqlite\v3\where.c(2088): remark #1599: declaration hides variable "i"
(declared at line 2026)
int i, j, last;
^
Re: [sqlite] SQLite -- Very Slow -- ??
I usually create a worker thread to send log lines through UDP to a syslog. UDP is damm fast and you do not have to wait.
Re: [sqlite] Thread handling in Windows
I'm the one who posted ticket 1601. I have a multithreaded sqlite tcp server, and it ran fine with 2.8.x and 3.x versions, but this "feature" is a stopper for me. I think there is no difference using a dll or not, there is no way to free that thread memory allocated, since that function it uses static variables. Some have stated using DLL_THREAD_DETACH, but this only works (in case it does work) using the dll, if linked statically it keeps leaking memory. As drh stated: "In the unix world using pthreads, when you allocate thread-local storage, you specify a callback function to delete the storage when the thread terminates. This callback is the second argument..." Ok, and what is it suppose to do that callback being that info internal to sqlite, and thus not exposed? The problem arises when sqlite uses (malloc) thread memory but itself does not create/terminate threads. An application that uses sqlite is the one that knows about threads, modules, libraries, etc. ie., when they are created/terminated, thread id, priority, library (dll) loading/unloading, and so on. I've always thought (since I began using sqlite) about a couple of public functions (and exported in the "def" file) like: InitSqliteLib and DeInitSqliteLib. These would take care of all the public variables, hash lists and so forth to make a clean start and exit. Extending this, maybe a couple more but for threads, like (exported in the "def" file): InitSqliteThread and DeInitSqliteThread. So right after creating a thread that is going to use sqlite functions, it would call InitSqliteThread, which would allocate, initialize or whatever it needs for the current thread, and right before terminating the thread it would call DeInitSqliteThread. Same for the InitSqliteLib and DeInitSqliteLib. This way, it would be possible to get it working using pthreads, Windows threads and others.
[sqlite] Intel 9.0 compiler warnings
Just for the records.
I just compiled sqlite 3.2.8 with a new compiler (Intel 9.0) and gives these
warnings (among many others):
attach.c
.\Sqlite\v3\attach.c(142): remark #1599: declaration hides variable "i"
(declared at line 34)
int i = db->nDb - 1;
date.c
.\Sqlite\v3\date.c(506): remark #1572: floating-point equality and
inequality comparisons are unreliable
&& (n=r)==r && n>=0 && r<7 ){
^
.\Sqlite\v3\date.c(611): remark #1572: floating-point equality and
inequality comparisons are unreliable
if( y!=r ){
^
.\Sqlite\v3\date.c(819): remark #1599: declaration hides variable "n"
(declared at line 756)
int n; /* Number of days since 1st day of year */
^
delete.c
.\Sqlite\v3\delete.c(206): remark #1599: declaration hides variable "addr"
(declared at line 89)
int addr;
^
expr.c
.\Sqlite\v3\expr.c(1370): remark #1599: declaration hides variable "i"
(declared at line 1350)
int i;
^
.\Sqlite\v3\expr.c(1521): remark #1599: declaration hides variable "op"
(declared at line 1446)
int aff, op;
^
insert.c
.\Sqlite\v3\insert.c(301): remark #1599: declaration hides variable "base"
(declared at line 201)
int base = sqlite3VdbeCurrentAddr(v);
^
.\Sqlite\v3\insert.c(685): remark #1599: declaration hides variable "base"
(declared at line 201)
int base = sqlite3VdbeCurrentAddr(v);
^
pager.c
.\Sqlite\v3\pager.c(1472): remark #1599: declaration hides variable "nRec"
(declared at line 1402)
u32 nRec;
.\Sqlite\v3\pager.c(2337): remark #1599: declaration hides variable "rc"
(declared at line 2305)
int rc;
^
.\Sqlite\v3\pager.c(2431): remark #1599: declaration hides variable "rc"
(declared at line 2305)
int rc = syncJournal(pPager);
^
.\Sqlite\v3\pager.c(2523): remark #1599: declaration hides variable "rc"
(declared at line 2305)
int rc;
^
parse.c
parse.c(1276): remark #1418: external definition with no prior declaration
(could be made static)
const char *sqlite3ParserTokenName(int tokenType){
^
vdbe.c
.\Sqlite\v3\vdbe.c(233): remark #1572: floating-point equality and
inequality comparisons are unreliable
if( ((double)pRec->i)==pRec->r ){
^
.\Sqlite\v3\vdbe.c(1056): remark #1572: floating-point equality and
inequality comparisons are unreliable
if( a==0.0 ) goto divide_by_zero;
^
.\Sqlite\v3\vdbe.c(1063): remark #1572: floating-point equality and
inequality comparisons are unreliable
if( ia==0.0 ) goto divide_by_zero;
^
vdbeaux.c
.\Sqlite\v3\vdbeaux.c(922): remark #1599: declaration hides variable "rc"
(declared at line 909)
int rc;
where.c
.\Sqlite\v3\where.c(427): remark #1599: declaration hides variable "k"
(declared at line 416)
int k;
^
.\Sqlite\v3\where.c(2021): remark #1599: declaration hides variable "i"
(declared at line 1959)
int i, j, last;
^
[sqlite] new callback for needed functions
I think it would be useful to have a function like sqlite3_function_needed called from the parser (or whatever module) to give the application an opportunity to register the needed function seen in a SQL statement. The idea came up from the sqlite3_collation_needed function which registers a callback when a not already registered collation is seen/needed. Having this new function, only the used funtions so far would be registered (like collations) thus saving time and memory. Sqlite internals (func.c) could also benefit from this api. This would speed up the sqlite3_open call (which registers all the built in functions.)
[sqlite] temp_store_directory
Shouldn't temp_store_directory be private to a sqlite3 structure? Currently it is global (in os_*.c), so setting a value through the pragma affects to all currently opened sqlite connections within the process which may be undesirable. I guess the basic idea is to keep as minimum global variables as posible. Also, in case the library is loaded, unloaded and reloaded, the known "not memory leak" (sqlite3 global data only released at app exit) will be a true memory leak since that memory segment belong to the process. I see this in case one would like to dinamically load/unload the library to update de sqlite library without stopping the app. To achieve this the only needed functions would be some of Sqlite3InitLib and Sqlite3DeInitLib. I can imagine (actually ofuscated) apps like a sqlite library distribution server, if a new version is out, then the app could retrieve, unload and load it again safely without leaks.
Re: [sqlite] Re: *** Please help ***
Read the documentation: "The first parameter is a prepared SQL statement. If this statement is a SELECT statement, the Nth column of the returned result set of the SELECT is a table column then the declared type of the table column is returned. If the Nth column of the result set is not at table column, then a NULL pointer is returned." - Original Message - From: "EzTools Support" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 20, 2004 11:43 PM Subject: [sqlite] Re: *** Please help *** > Can someone please please answer the question, does > sqlite3_column_decltype NOT return the column type for Views? I don't > see how this wouldn't considered as a major bug. > > > EzTools Support wrote: > > > > > I found out why Views were returning all NULLs. I have made a > > modified version of sqlite3_exec. Mine checks for NULL returned from > > sqlite3_column_decltype, for which Sqlite3 now returns NULL. Am I > > right that this is so? My COM wrapper depends on having the column > > data types returned for Views. Can you please make it work again, as > > this is vital. > > > > thanks > > -brett > > > > > > EzTools Support wrote: > > > >> Hello. Can someone please help with this issue. It may turn out to > >> be a bug in Sqlite 3. > >> > >> I have the following fairly basic SQL View that works fine with > >> Sqlite 2.x: > >> > >> CREATE VIEW Invoices AS > >> SELECT Customers.CustomerID, Customers.CompanyName,Orders.OrderID, > >> OrderDetails.ProductID, OrderDetails.Quantity FROM Customers INNER > >> JOIN Orders ON Customers.CustomerID = Orders.CustomerID INNER JOIN > >> OrderDetails ON Orders.OrderID = OrderDetails.OrderID > >> > >> When I create and run this view in 3.x, I get all of the rows back, > >> but all values are NULL! > >> > >> If I run the SELECT statement apart from the view, it I get the data > >> back fine. But if I select * FROM Invoices, I get all of the rows > >> back, but all values are NULL. > >> > >> Another interesting thing is that when selecting from the View, the > >> column names are without the table prefix. That is, CustomerID, > >> CompanyName, OrderID, et. But if I select from the tables directly, > >> the column names have the table prefix, Customers.CustomerID, > >> Customers.CompanyName, Orders.OrderID > >> > >> I have put the database up on my website here (Zip file): > >> > >>www.eztools-software.com/downloads/northwind.zip > >> > >> This is happening in all version 3.0.5-3.0.7. Can someone please > >> download this DB and investigate. > >> > >> If you want to test the same view and data with a v2.x database, you > >> can get the SqlitePlus28 download from here: > >> > >>www.eztools-software.com/downloads/sqliteplus.exe > >> > >> TIA > >> -Brett Goodman > >> > >> > > >
[sqlite] temporary databases
Shouldn't vdbeaux.c line 753: rc = sqlite3BtreeFactory(db, ":memory:", 0, TEMP_PAGES, >pBtree); obey the TEMP_STORE macro so it is stored either in memory or disk? I know it's there for speed, but that's what TEMP_STORE is for. Isn't it? If I change in that line the ":memory:" to a 0 (zero), would I break anything? Also it seems the parser "supports" something weird: CREATE TABLE table1 (field1 integer); CREATE TABLE table2 (field2 integer); INSERT INTO table1 (field1) VALUES (1); INSERT INTO table2 (field2) VALUES (2); SELECT table1. field1, table2. field2 FROM table1, table2; Note the extra spaces between tables and fields in SELECT.
Re: [sqlite] SQLite & stack size
It's not really (or not only) Windows the culprit but rather the compilers that implement lazy memory managers. In my experience, Borland had rather slow functions, always beaten by microsoft (sorry :( ). For instance, there are out some C compilers like LCC that (as I'm told) does not implement any memory manager but passes the calls to the OS. As far as I know, MS Visual C memory manager is quite fast. If one have problems with the malloc's, maybe they could be inside ifdef's to use one style or another. - Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 03, 2004 8:43 PM Subject: Re: [sqlite] SQLite & stack size > Christian Smith wrote: > > > > How often does the balancer run? > > > > No so much, it turns out. Long ago, it used to run a lot > more often and was a high runner. But I've since optimized > it out of a lot of situations. > > So allocating with malloc() isn't a big performance hit > after all (at least not on systems where malloc performs > well - I haven't tried it on windows...) I've checked in > the changes so that btree.c now allocates all of its big > temporary data structures using malloc instead of allocating > them off of the stack. > > Let me know if you see any problems > > -- > D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 >
[sqlite] v3 assert with explain
Using v.3.0.5 and executing: explain pragma page_size; or whatever pragma is entered, it throws an assert in function sqlite3VdbeSetNumCols called from main.c line 1037: sqlite3VdbeSetNumCols(sParse.pVdbe, 5);
[sqlite] v3 pragmas
I just discovered that malformed pragma's statements return SQLITE_DONE. For instance "pragma table_info (foo);" if table "foo" does not exist, SQLITE_DONE is returned. Also occurs in completely malformed pragma's like "pragma x;". Also verified in v.2.8.13 One question: I'm returning a recordset to the user, and I'm assuming that if the return error code is SQLITE_OK and sqlite3_column_count () == 0 then it is not a select. But the pragma "bug" above fails with this assumption. Is there any way to know the type of the current statement, i.e.: select, insert, delete, etc? I would like to know it to retrieve the sqlite3_changes() value after the statement has finished to return that value to the user.
Re: [sqlite] v3 like and collation
>You are correct that LIKE and GLOB only work for 7-bit ascii >strings. If you need a LIKE and GLOB that work with Unicode, >you can register alternative LIKE and GLOB functions using >the sqlite3_create_function() API. Yes, I know it can be done that way. BTW, I'm not using Unicode. :) I meant "conceptually" comparing text and matching a string is quite the same. Why involving new user functions to match a string (and duplicating code) when we have collations wich compare text? So intead of passing the string to lower case (through the macro in utf.c), I guessed it could use the defined collation function (if any or the default). With all this, it would be easy to perform case insensitive as well as case sensitive LIKE and GLOB function calls just substituting the collation function int the sql statement. BTW. Another workaround would be registering and using a function but without replacing the LIKE and GLOB functions like: select * from foo where col1 like myfunction (somevalue) I think it would work.
[sqlite] v3 like and collation
Shoudn't the LIKE and GLOB function use a collation if present (either in column definition or by the COLLATE xxx word) ? The new collation functions are used to compare strings, and that's what LIKE and GLOB do (sort of). That way it would correctly handle the > ASCII(127) characters. -- Miguel
[sqlite] v3 high memory consumption
Hi all. I have a db v.3.0.1 of 32Mb with a single table and 598356 rows (no indexes). Doing a insert xx into select ... using no joins, only sums and groups by, it takes hours to complete. Besides RAM comsumption raises up to 500MB or more till I ran out of virtual memory. Rows are small in size. I guess to do a group by one would have to sort rows and sorting is using RAM. Could this explain it? I've change vdbeaux.c line 773 to not use the sqlite3BtreeFactory (db ":memory:",...) but it didnd't help. I'm a bit concerned about the high memory consumption using "group by" (and posibly other statements). I have the db (zipped is "only" 15MB) and a script to run with the .read metacommand if anyone is interested. By the way, the same happens with 2.x versions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Bug or it makes sense?
Kenneth: Thanks, I see your point, but that was just an example, put an "insert" or "delete" command instead of the "create table", and that row would be "inserted" or "deleted" without executing a rollback due to the SQL error. I haven't tested though. But perhaps, as you said, the create table makes its own transaction, but that shouldn't bother the rest of statements included in the explicit "outer transaction". Should it? I might be missing something but any number of statements surrounded by a begin/commit should all be done or undone. - Original Message - From: "kenneth long" <[EMAIL PROTECTED]> To: "Miguel_Angel_Latorre_Díaz" <[EMAIL PROTECTED]> Sent: Friday, June 25, 2004 7:31 PM Subject: Re: [sqlite] Bug or it makes sense? > Miguel, > > I suspect that similar to most SQL languages the > "Create" statements are their own transactions and > perform an automatic commit.. Thats the way Oracle > performs as do many others. > > > > --- Miguel_Angel_Latorre_Díaz > <[EMAIL PROTECTED]> wrote: > > Ok. But if one just does (also tried with the .read > > metacommand): > > sqlite3_exec (db, "begin; create table foo (value1 > > integer, value2 integer); > > just an error; commit;", rest of params...) > > > > should it do the same? > > To me, the "begin; ..." is a whole multi statement > > which should be done > > whitin a transaction because of the "begin". So, all > > or nothing, but I get a > > mixture. > > > > > > > - > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > __ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] Proposal for SQLite 3.0
I think version 3.x should do sorting and grouping on disk. Using temporary tables? Once we have btrees, why not using them? It may not be the fastest way of doing it, but it saves lots of memory. Perhaps it could begin doing it in memory and when reaching some certain value it could use the external method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
