Re: [sqlite] Compilation problems after upgrading from v3.7.6.3 to v3.8.4
It seems that the compilation errors i reported earlier error C2099: initializer is not a constant ..\sqlite3\sqlite3.c 73531, etc only occured in debug mode, and, were caused by flag: Program Database for Edit And Continue (/ZI) after changing the flag to: Program Database (/Zi) everything is compiling normally again both in debug and release mode. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Compilation problems after upgrading from v3.7.6.3 to v3.8.4
I am having compilation problems after upgrading from v3.7.6.3 to v3.8.4 on
the
static const int iLn = __LINE__+4; < lines containing these statements
Tried with VS2012 and VS2013, can someone help me fix this ?
error C2099: initializer is not a constant ..\sqlite3\sqlite3.c 73531
error C2099: initializer is not a constant ..\sqlite3\sqlite3.c 97602
error C2099: initializer is not a constant ..\sqlite3\sqlite3.c 97865
error C2099: initializer is not a constant ..\sqlite3\sqlite3.c 98568
error C2099: initializer is not a constant ..\sqlite3\sqlite3.c 106055
Additionally i was wandering, whether the following is correct.
__LINE__+4 seems to point to the commented line !!!
73527 ** The sqlite3_blob_close() function finalizes the vdbe program,
73528 ** which closes the b-tree cursor and (possibly) commits the
73529 ** transaction.
73530 */
73531 static const int iLn = __LINE__+4;
73532 static const VdbeOpList openBlob[] = {
73533/* {OP_Transaction, 0, 0, 0}, // 0: Inserted separately */
73534{OP_TableLock, 0, 0, 0}, /* 1: Acquire a read or write lock
*/
73535/* One of the following two instructions is replaced by an
OP_Noop. */
73536{OP_OpenRead, 0, 0, 0},/* 2: Open cursor 0 for reading */
73537{OP_OpenWrite, 0, 0, 0}, /* 3: Open cursor 0 for read/write
*/
73538{OP_Variable, 1, 1, 1},/* 4: Push the rowid to the stack */
Thanks in advance!
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 'no such column' error returned in a CASE statement
Pavel Ivanov-2 wrote: > > > Yes, it's expected. Column aliases are visible only in GROUP BY/ORDER > BY/HAVING clauses and outer selects. All other places should use exact > column expression instead. > > Pavel > > Ah, thanks Pavel for the clarification, now it makes sense. This is a bit inconvenient but i guess i can use a VIEW for the second select. I noticed that the same applies for aggregate functions in the select statement. I was searching for some documentation in the sqlite site but didn't find anything so i guess this is defined in the SQL standard. -- View this message in context: http://old.nabble.com/%27no-such-column%27-error-returned-in-a-CASE-statement-tp30113686p30123189.html Sent from the SQLite mailing list archive at Nabble.com. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] 'no such column' error returned in a CASE statement
The following error 'no such column: A' is returned when i execute the following statement. SELECT 'test' as A,CASE WHEN A = 'test' THEN 'true' ELSE 'false' END as ERRVAL Is this the expected result or should the generated column be available to the case statement. Thanks. -- View this message in context: http://old.nabble.com/%27no-such-column%27-error-returned-in-a-CASE-statement-tp30113686p30113686.html Sent from the SQLite mailing list archive at Nabble.com. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite3_create_function_v2 not available for extensions
sqlite3_create_function_v2 function is not defined in sqlite3ext.h hence not available for use in extensions. -- View this message in context: http://old.nabble.com/sqlite3_create_function_v2-not-available-for-extensions-tp29926215p29926215.html Sent from the SQLite mailing list archive at Nabble.com. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Mistake in documentation and question
In page http://www.sqlite.org/datatype3.html under section 3.2 Affinity Of Comparison Operands 2nd bullet point should read: An expression "CAST(expr AS type)" instead of "CAST(expr TO type)" In addition a quick question. Is there a way to perform a division of two columns (real type) and force the result to be presented/rounded in 2 decimal places ? Thanks -- View this message in context: http://old.nabble.com/Mistake-in-documentation-and-question-tp29387429p29387429.html Sent from the SQLite mailing list archive at Nabble.com. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Possible UNICODE LIKE, upper(), lower() function solution
Dear all SQLite3 users, Recently i have been working on a dictionary style project that had to work with UNICODE non-latin1 strings, i did try the ICU project but i wasn't satisfied with the extra baggage that came with it. I would like to recommend the following possible solution to the long standing UNICODE issue, that was built in as an ICU alternative (excluding collation's), and could be easily be included in the SQLite core as default behavior. http://ioannis.mpsounds.net/blog/?dl=sqlite3_unicode.c The above file contains mapping tables for lower(), upper(), title(), fold()* characters based on UNICODE mapping tables as described currently by the UNICODE standard v5.1.0 beta, that are used by functions to transform characters to their respective folding cases. (These tables were built by a modified version of Loic Dachary builder in order to included required case transformations) * UNICODE uses case folding mapping tables to implement non-case sensitive comparison sequences (eg LIKE). The above file utilizes the existing ICU infrastructure built in SQLite in order to activate the extra functionality, to automatically : - override the LIKE operation, to support full UNICODE non-case sensitive comparison - override upper(), lower(), to support case transformation of UNICODE characters based on UNICODE mapping tables as described currently by the UNICODE standard v5.1.0 beta - provide title() and fold() functions, also based on UNICODE mapping tables as described currently by the UNICODE standard v5.1.0 beta - provide unaccent() function, (based on the unac library designed for linux by Loic Dachary) to decompose UNICODE characters to there unaccented equivalents in order to perform simpler queries and return wider range of results. (eg. ά -> α, æ -> ae in the latter example the string will automatically grow by 1 character point) In comparison to ICU no collation sequences have been implemented yet. The above functionalities have been designed to be included/excluded independently according to specific needs in order to minimize the size of the library. The total overhead over the SQLite library size with all functionality enabled is approximately 70~80KB. The above file has not been thoroughly tested, but i consider the implementation to stable. You can leave comments, bug reports, suggestions on this board or at http://ioannis.mpsounds.net/blog/2007/12/19/sqlite-native-unicode-like-support (PS. I am not an SQLite expert, but i had to improvise on some extent on this matter.) Thank you very much.
