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

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

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

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

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

[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

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

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

[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

[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

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

[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),

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

[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

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

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

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

[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