Re: [sqlite] SQLite Android Bindings: how difficult to add LOCALIZED back?
On 01/11/2015 01:55 PM, Philip Warner wrote: On 9/01/2015 5:00 PM, Dan Kennedy wrote: On 01/08/2015 07:48 AM, Philip Warner wrote: How difficult would it be to add LOCALIZED collation support? I'm guessing that the fact it's not there means it's non-trivial, but I was hoping otherwise... The stumbling block is that the Android implementations use ICU. So to use the Android versions I think we would have to build ICU as a static library as well as SQLite. And ICU is quite large. Thanks for this; I was naively (again) hoping they might have built the unicode stuff as something that was dynamically linkable. I must admit the benefits of a recent build + ability to build custom functions etc is very appealing. btw, do you have an estimate of how big quite large might be? Please review the stuff recently added to AndroWish's Tcl SQLite interface on http://www.androwish.org/index.html/info/84d5ed5ae9c24bada8f8b9f9f198306a1e59300a It tries to use whatever ICU infrastructure is already available on the device by using dynamic linking. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Accented characters and ODBC
Greg Bryant wrote: Not sure if ODBC questions belong here, feel free to point me to a better forum. I'm using current SQLite (3.7.2) via a visual c++ app. We're connecting a sqlite3 database via ODBC (driver from , also current version - 0.87). If I do either an insert or update using an accented character (e.g. André), it works fine, and I can check it using anything that directly connects to the database (I've been using SQLiteStudio and SQLiteAdmin) and it looks fine. When I go to do a select via the ODBC connection, however, I get back garbage for the accented character (specifically, I get AndrÃfÆ?©). I don't think the app settings are a problem, since the accent works fine through the insert, and step into doesn't get me past the SQLFetch from Microsoft's odbc layer, and I don't think it's sqlite, since it appears to be correct when viewed through a direct connection, which just leaves the odbc layer. Does anyone have any pointers on where I can look to figure this out? How do you retrieve character data? When using SQL_C_CHAR the 0.87 version of the driver outputs UTF-8 strings whereas your application deals most likely with codepage 1251 (Windows Latin-1). When you use SQL_C_WCHAR everything should be fine. You might also try out a pre-release which has UTF-8 to/from CP_OEMCP/CP_ACP built into the SQLite3 driver, it is on http://www.ch-werner.de/sqliteodbc/sqliteodbc-088pre2.exe OTOH, I'm not familiar with SQLiteStudio and SQLiteAdmin, do these insert/update UTF-8 encoded strings? Regards, Christian ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Port SQLite to VxWorks
ÕÅÊÀÎÅ wrote: Hi, all. I am new to SQLite database and encountered a big problem. I intend to port SQLite to VxWorks OS and don't really know how. When directly compiled the source code downloaded from the official site in VxWorks' IDE Tornado, I kept receiving messages of certain header files missing. I've heard that VxWorks is POSIX compliant and SQLite works well in POSIX systems, but the compilation just don't work. Do any of you have experience of porting SQLite to VxWorks? Is there any modificaiton needed to achieve this? Any help will be appreciated. The SQLite source tarball (e.g. www.sqlite.org/sqlite-3.6.14.tar.gz) has support for vxworks = 6.4 in RTP (real-time process) mode which has been tested in x86 emulation of vxworks on a Linux/i386 development system and on real hardware (PowerPC). Although the necessary defines are in the os_unix.c and other modules, SQLite as a vxworks kernel module has not been tested. For details on building, please consult the Makefile.vxworks in the source tarball. Best regards, Christian ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ResultSetMetaData with javasqlite
Justin Deoliveira wrote: Hi Justin, Thanks for the quick response. I am not sure if this will be of any help or not but I wrote this (very crude) patch to get around the problem: http://files.opengeo.org/sqlite_jni.c.patch ... Based on your patch there's now a improved version in http://www.ch-werner.de/javasqlite Best regards, Christian ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ResultSetMetaData with javasqlite
Justin Deoliveira wrote: Justin, I have ran into an issue while using the javasqlite jdbc wrapper.The issue can be illustrated with the following code: ... you're right, I've verified that behaviour with SQLite 3.x databases. The problem cannot be observed with SQLite 2.x databases. Basically it seems that the result set metdata is not properly initialized when a query returns no rows. I guess my question is is this a bug or is it intended behavior? Unintended consequences but present since the initial support for SQLite 3.x in 2004. Thus let's call it a misfeature. I'm working on a solution. Best regards, Christian ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite.Exception: not authorized (to load a shared librarywith SQLite Java Wrapper/JDBC Driver)
Bejay Bamboo wrote:
Hello,
i'm trying to load new SQL functions from a shared library with the
help of the SQLite Java
Wrapper/JDBC Driver (http://www.ch-werner.de/javasqlite). I'm trying
java -cp :. -Djava.library.path=/tmp/javasqlite-20090213/.libs
SQLite.Shell db select
load_extension('/tmp/spatialite-2.2-linux-x86-libs/lib/libspatialite.so')
I get the following SQL Error:
SQL Error: SQLite.Exception: not authorized
Same error in the small test program
(http://www.ch-werner.de/javasqlite/test.java) i ve added the
following line:
db.exec(select
load_extension('/tmp/spatialite-2.2-linux-x86-libs/lib/libspatialite.so'),new
test());
The following statements are fully working in sqlite:
sqlite select
load_extension('/tmp/spatialite-2.2-linux-x86-libs/lib/libspatialite.so');
sqlite .load /tmp/spatialite-2.2-linux-x86-libs/lib/libspatialite.so
Did I misunderstood something? Did i trying something which is not
provided by the SQLite Java
Wrapper/JDBC Driver?
In order to enable loading an extension the SQLite API
sqlite_enable_load_extension() must be called but there's
currently no method to call it from Java code for
security reasons.
HTH,
Christian
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ODBC driver C source file includes a header which was notshipped
Abshagen, Martin RD-AS2 wrote: Hi, am trying to use the Sqlite3 ODBC driver for C, provided by Christian Werner (http://www.ch-werner.de/sqliteodbc/, product sqliteodbc-0.77-1.src.rpm). If _WIN32 is defined, sqlite3odbc.c includes a resource3.h header file, which is not shipped with the version. How could I work around or find resource3.h? The resource3.h file is generated from resource.h.in, see the Makefile.mingw-cross for the sed command line. See also the mingw-cross-build.sh script on how the drivers and SQLite are built. HTH, Christian ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] export to SQL insert statements with column names
[EMAIL PROTECTED] wrote:
Hi,
Is there a way to export/dump SQLite data into INSERT statements which
also have column names?
As of now, a sqlite dump looks like this
INSERT INTO ric_tb_language VALUES('ENG','English');
INSERT INTO ric_tb_language VALUES('SPN','Spanish');
INSERT INTO ric_tb_language VALUES('GER','German');
Is it possible to have it like below(column names included)?
INSERT INTO ric_tb_language (ID, language) VALUES('ENG','English');
INSERT INTO ric_tb_language (ID, language) VALUES('SPN','Spanish');
INSERT INTO ric_tb_language (ID, language) VALUES('GER','German' );
You might find the impexp.c source file in the SQLite ODBC
driver on http://www.ch-werner.de/sqliteodbc useful for this purpose.
It implements some SQLite 3 extension functions. The export_sql()
function should produce your desired output format if invoked as
select export_sql('filename', 1, 'ric_tb_language');
HTH,
Christian
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] ANN: SQLite ODBC driver version 0.77 released
Dear all, version 0.77 of the SQLite ODBC driver is available for download from http://www.ch-werner.de/sqliteodbc It's Windows one-click installer is built with SQLite 3.5.4 and 2.8.17. There were two major bug fixes with respect to wide-char parameter binding and wide-char data retrieval, thus an update is suggested. Happy new year, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Compiling Problem With SQLite 3.5.4
[EMAIL PROTECTED] wrote: ... The warnings all have to do with the fact that you are compiling on a machine with 64-bit pointers and 32-bit integers. The warnings are all harmless and the code works as intended as long as sizeof(int) = sizeof(void*) Perhaps a reader can suggest ways of eliminating these warnings. What about using the ptrdiff_t type in those places instead. Cheers, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Compiling Problem With SQLite 3.5.4
[EMAIL PROTECTED] wrote: Christian Werner [EMAIL PROTECTED] wrote: What about using the ptrdiff_t type in those places instead. Is ptrdiff_t implemented on all C compiler environments that SQLite builds on? I'm afraid not, thus some autoconf logic might be required to detect its availability. Also, will it really eliminate the warnings. In several places we are storing a (32-bit) integer in a pointer. p = (char*)i; And then later we get the integer back out: i = (int)p; When the context allows to change i's type to ptrdiff_t then you get i = (ptrdift_t)p; which eliminates the warning. If we change to ptrdiff_t, then we have: p = (char*)(ptrdiff_t)i; /* Convoluted, but works */ i = (int)(ptrdiff_t)p;/* Still get a warning? */ In the conversion from pointer back to integer, don't we still get a warning about casting a 64-bit integer into a 32-bit integer? (I don't know because I do not have a 64-bit machine easily at hand to test it on.) See above, when it's irrelevant if i is a 32 or 64 bit data type, the 32 vs. 64 bit warning blues is gone. Regards, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Compiling Problem With SQLite 3.5.4
Following patch applied to the CVS version compiled
w/o warnings on a CentOS 5 x86_64 box. But I didn't
run the test yet ... and autoconf logic regarding
availability of ptrdiff_t is missing, too.
Index: src/func.c
===
RCS file: /sqlite/sqlite/src/func.c,v
retrieving revision 1.181
diff -r1.181 func.c
878c878
int flags;/* 1: trimleft 2: trimright 3: trim */
---
ptrdiff_t flags; /* 1: trimleft 2: trimright 3: trim */
919c919
flags = (int)sqlite3_user_data(context);
---
flags = (ptrdiff_t)sqlite3_user_data(context);
1464c1464
pArg = (void*)(int)argType;
---
pArg = (void*)(ptrdiff_t)argType;
1483c1483
void *pArg = (void*)(int)aAggs[i].argType;
---
void *pArg = (void*)(ptrdiff_t)aAggs[i].argType;
Index: src/table.c
===
RCS file: /sqlite/sqlite/src/table.c,v
retrieving revision 1.29
diff -r1.29 table.c
36c36
int nData;
---
ptrdiff_t nData;
197c197,198
int i, n;
---
int i;
ptrdiff_t n;
200c201
n = (int)azResult[0];
---
n = (ptrdiff_t)azResult[0];
Index: src/vdbemem.c
===
RCS file: /sqlite/sqlite/src/vdbemem.c,v
retrieving revision 1.84
diff -r1.84 vdbemem.c
878c878
if( (enc SQLITE_UTF16_ALIGNED)!=0 1==(1(int)pVal-z) ){
---
if( (enc SQLITE_UTF16_ALIGNED)!=0 1==(1(ptrdiff_t)pVal-z) ){
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
[sqlite] ANN: SQLiteODBC Driver 0.76
Version 0.76 of the SQLiteODBC Driver is ready for download from http://www.ch-werner.de/sqliteodbc The Win32 installer is build with SQLite 3.5.1 and 2.8.17. Enjoy, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] SQLite 2 to SQLite 3 - Varchar sizes
Mitchell Vincent wrote: I have an old SQLite 2.8 database that shared it's schema with PostgreSQL. One of the nifty things about PostgreSQL (that admittedly has me spoiled) is the ability to just say varchar without any length specifier. Specifying varchar in SQLite works great - no problem at all. Until I tried to use it with ODBC. The SQLite ODBC driver works fine but assumes a 255 character limit. As soon as it returns a result longer than 255 it blows an error. I see in the SQLite ODBC driver's documentation that it does support 255 varchar fields but I _assume_ have to specify that it's 255 in the schema. Now comes the fun part. I'm converting these databases (and there are a LOT of them), I'm doing sqlite OLD.DB .dump | sqlite3 NEW.DB which works flawlessly. Is there any way to change the schema on the fly to say Varchar(1024) instead of just varchar (or just use an SQLite 'type' of text) ? Mitchell, the artificial limitation of VARCHAR columns to 255 chars in the SQLite ODBC drivers is yet another tribute to M$ACCE$$. If you want a proper untruncated mapping to larger VARCHAR columns use text or memo in your CREATE TABLE statement. These will be mapped to SQL_LONGVARCHAR by the drivers. Sorry for that inconvenience, but blame billg, not me ;-) Regards, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Last ID from Primary Key through ODBC
Dan Kennedy wrote: On Sat, 2007-03-03 at 19:18 -0500, Mitchell Vincent wrote: I found the nifty ODBC driver for SQLite and have been trying to use it to replace a 2.8 SQlite implementation in some desktop software. It's working very well except for a rather large problem of not being able to call the last_id API functions. I need to get the primary keys assigned to parent tables in order to preserve referential integrity. SELECT MAX(id) FROM TABLE is one option but it's pretty dangerous seeing as multipl people *could* be accessing this database file at the same time.. What if you wrap the INSERT and SELECT MAX(id) statements together in a transaction? Or what about issuing a SELECT last_insert_rowid() ? Regards, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] ANN: SQLite ODBC Driver 0.73
Noah Hart wrote: Hello Christian, I tried your odbc driver, and it works pretty well, but does not handle Unicode at all. I have a dictionary application with two columns, first being English, second being Punjab (stored in Unicode) For example, simple table with EN_WORD PJ_WORD === === Punjabi ਪੰ�ਾਬ� If I link a sqlite3 table via access and run a query to insert into the table, I get gibberish in the sqlite3 database. Did you support Unicode in your odbc driver? Noah, IMO the SQLite3 driver starting with version 0.71 (as well as the SQLite3 UTF-8 driver) does support UNICODE. There could be some olden Accesses which don't use the SQLWCHAR ODBC APIs. Did you try that simple table with OpenOffice 2.0.* Base with UTF-8 as Base's encoding ? Regards, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] ANN: SQLite ODBC Driver 0.73
Hi all, release 0.73 of the SQLite ODBC driver is available for download from http://www.ch-werner.de/sqliteodbc From the change log: * update to SQLite 3.3.13 * SQLGetInfo(SQL_OWNER_TERM) now is empty string * fixed bug in Win32 version concerning SQLDriverConnect() * added -L/-l/-I/-i switches to sqlite+tcc.c Cheers, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] ANN: SQLiteODBC Driver 0.72
Version 0.72 of the SQLiteODBC Driver is ready for download from http://www.ch-werner.de/sqliteodbc It now supports loadable extensions as of SQLite = 3.3.7 in the form of a DSN option. The one-click Win32 installer is based on SQLite 3.3.12 and contains the FTS1/FTS2 extensions and the experimental SQLite+TCC from www.sqlite.org/contrib Enjoy, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] ANN: SQLiteODBC Driver 0.72
Joe Wilson wrote:
Nice job on the new driver.
The new DSN parameter LoadExt=module1.dll,module2.dll for dynamically
loadable sqlite extension modules is particularly useful.
The SQLite+TCC extension is very cool.
Thank you, Joe!
If only I had added that patch to sqlite+tcc.c erlier
---snip---
--- sqlite+tcc.c.old2007/01/28 10:58:04
+++ sqlite+tcc.c2007/02/10 17:07:10
@@ -178,6 +178,10 @@
unsigned long val;
void (*xInit)(void *);
sqlite3 *db = sqlite3_user_data(ctx);
+ if( argc1 ){
+sqlite3_result_error(ctx, need at least one argument, -1);
+return;
+ }
#ifdef _WIN32
EnterCriticalSection(tcc_mutex);
#endif
@@ -190,11 +194,25 @@
return;
}
tcc_set_output_type(t, TCC_OUTPUT_MEMORY);
+ for( i=1; iargc; i++ ){
+char *p = sqlite3_value_text(argv[i]);
+if( p p[0]=='-' p[1]=='L' p[2] ){
+ tcc_add_library_path(t, p+2);
+}else if( p p[0]=='-' p[1]=='l' p[2] ){
+ tcc_add_library(t, p+2);
+}else if( p p[0]=='-' p[1]=='I' p[2] ){
+ tcc_add_include_path(t, p+2);
+}else if( p p[0]=='-' p[1]=='i' p[2] ){
+ tcc_add_sysinclude_path(t, p+2);
+}else if( p p[0]!='-'){
+ tcc_add_file(t, p);
+}
+ }
if( tcc_compile_string(t, sqlite3_value_text(argv[0])) ){
sqlite3_result_error(ctx, compile error, -1);
goto error;
}
- for( i = 0; symtab[i].name; i++ ){
+ for( i=0; symtab[i].name; i++ ){
val = ((unsigned long *) ((char *) sqlite3_api + symtab[i].offs))[0];
if( val ){
tcc_add_symbol(t, symtab[i].name, val);
@@ -237,7 +255,7 @@
const sqlite3_api_routines *api /* SQLite3 API entries */
){
SQLITE_EXTENSION_INIT2(api);
- if( sqlite3_create_function(db, tcc_compile, 1, SQLITE_UTF8, db,
+ if( sqlite3_create_function(db, tcc_compile, -1, SQLITE_UTF8, db,
tcc_compile, 0, 0) != SQLITE_OK ){
if( pzErrMsg ){
*pzErrMsg = sqlite3_mprintf(cannot create function);
---snip---
then the following piece of SQL would have had success
in compiling and not much later at run-time
(given the usual admin privileges of users on not unseen
Windozen ;-)
---snip---
.load 'sqlite+tcc.dll'
select tcc_compile('
#include windows.h
#include sqlite3.h
static void f(sqlite3_context *c, int n, sqlite3_value **a){
ExitWindowsEx(sqlite3_value_int(a[0]), 0);
}
void init(sqlite3 *db){
sqlite3_create_function(db, surprise, 1, SQLITE_ANY, 0, f, 0, 0);
}
','-luser32');
select surprise(0);
---snip---
Cheers,
Christian
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] ANN: SQLiteODBC Driver 0.72
Joe Wilson wrote: Hi Christian, I'm not sure what this patch to SQLite 3.3.12 does. Is it fixing a bug or extending SQLite for use in your ODBC driver? Should a ticket be created for it in SQLite CVSTrac? I've already created a low priority ticket for it, see http://www.sqlite.org/cvstrac/tktview?tn=2206 It's an extension which is useful for the BLOB to X/Y mapping module also part of the ODBC driver source code. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] SQLite JSON interface?
Michael Ruck wrote: Hi, Is there a JSON interface for SQLite (in C/C++)? Any GPL/LGPL compatible license or public domain would do. Someone must have written something like it. I need to export a set of tables to JSON .js files to serve on a webserver, the files are generated off-line, not on demand. Maybe the untested unsupported source code from http://www.ch-werner.de/sqliteodbc/sqlite3json.tgz can be used for that purpose. Cheers, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] ANN: SQLite ODBC driver 0.71
Howdy! Release 0.71 of the SQLite ODBC driver is ready for download from http://www.ch-werner.de/sqliteodbc (Main page) http://www.ch-werner.de/sqliteodbc/sqliteodbc.exe (Win32 Installer) http://www.ch-werner.de/sqliteodbc/sqliteodbc-0.71.tar.gz (Sources) The most important changes are: - improved support for pathnames with non-ASCII chars on Win32 - SQLite3 driver now provides wide-char APIs on Win32 - improved thread safety on Win32 - Win32 installer contains drivers built against SQLite 2.8.17 and 3.3.10 Best Regards, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem using loadable extension mechanism.
jima wrote: ... And then I go, no problems building. I have sqlite built with this feature I guess. But the thing is that I cannot make it to work. I prepared a c file following the template given in the wiki. I generated a .so using: gcc -I/path_to_sqlite-3.3.7/src -c -o Extension.o Extension.c Add the compiler switch -fPIC here. And gcc -shared -o Extension.so Extension.o /path_to_libsqlite3.so/libsqlite3.so Omit libsqlite3.so here, there's no need for it in the extension. ... When I do in sqlite3 prompt: ..load Extension.so Use the full path to Extension.so or prefix it with ./ Hope that helps, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem using loadable extension mechanism.
jima wrote: Thanks for the advice but it would not work either. I just tried with the flags you mentioned at compile time and full path when loading. Do you know if I have to enclose that full path in quotes or something at load time? like... ..load '/path/Extension.so' ? I tried several combinations of quotes but no luck here. I will recheck all what I have been doing just to make sure there is not an easy explanation for this... Did you rebuild your sqlite3 shell without -DSQLITE_OMIT_LOAD_EXTENSION and does an ldd on sqlite3 indicate that has libdl.so linked, e.g. $ ldd ./sqlite3 ... libdl.so.2 = /lib/libdl.so.2 (0x00402000) ... Then that sqlite3 shell command should do what you want: $ ./sqlite3 ... sqlite load './Extension.so' HTH, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Problem using loadable extension mechanism.
jima wrote: Hi, I build **without** -DSQLITE_OMIT_LOAD_EXTENSION I do ldd on sqlite3 and I get libdl.so.2 = /lib/libdl.so.2 (0x00402000) but I cannot load my Extension.so Do Extension.c has to include sqlite3.h ? Presently I am only including sqlite3ext.h. Including sqlite3ext.h is sufficient since it includes sqlite3.h. As DRH wrote in an earlier posting it is essential to place the magic macros in your extension source (SQLITE_EXTENSION_INIT1 outside of any function, and SQLITE_EXTENSION_INIT2 at the beginnig of your extension initialization function). If I have used --enable-thread at sqlite makefile configure time...can this cause an impact? I don't think so; you linked your sqlite3 shell with -lpthread already, right ? You can prove this with ldd sqlite3 HTH, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] [ANN] SQLite ODBC driver version 0.70
Version 0.70 of the SQLite ODBC driver is ready for download from http://www.ch-werner.de/sqliteodbc The Win32 installer now is made with SQLite 3.3.7. Enjoy, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] [ANN] SQLite ODBC driver version 0.68
Version 0.68 of the SQLite ODBC driver is ready for download from http://www.ch-werner.de/sqliteodbc It fixes some more bugs mainly in the SQLite 3.x version of the driver. Enjoy, Christian
Re: [sqlite] Compiling Sqlite JDBC driver (Compiler question)
[EMAIL PROTECTED] wrote: After I've been able to overcome the initial compiler problem (missing library installation), I'm faced with a new one: 1) Compiling JDBC wrapper for 3.2.1 works fine 2) Compiling JDBC wrapper for 3.3.5 fails: cl -Gs -EHsc -D_WIN32 -nologo -Zi -DOS_WIN=1 -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG=1 -DSQLITE_OMIT_CURSOR=1 -DWIN32=1 -DTHREADSAFE=1 -DOS_WIN=1 -DSQLITE_S OUNDEX=1 -I. -I..\sqlite-3.3.5/src -D_DLL -c ...\sqlite-3.3.5/src/alter.c alter.c ...\sqlite-3.3.5/src/alter.c(70) : error C2065: 'TK_SPACE' : undeclared identifier Regarding TK_SPACE, I've found that parse.y has changed between the two version, where 3.3.5 version now omits these lines: %nonassoc END_OF_FILE ILLEGAL SPACE UNCLOSED_STRING COMMENT FUNCTION COLUMN AGG_FUNCTION. I've not been able to figure out where or how TK_SPACE should be generated for the parse.h Please use the mkopc3.c source from the sqlite odbc driver instead. It should deal with this issue (poor MSWindows development systems weren't born with an awk :( another reason to switch to cygwin or mingw). Anybody volunteering for creating the build environment of javasqlite with the cygwin or mingw toolchain ? Regards, Christian
Re: [sqlite] Compiling Sqlite JDBC driver (Compiler question)
[EMAIL PROTECTED] wrote:
Christian,
I understand Windows is poor, but I do not fully understand the
compilation process. The mkopc3.exe is actually created- so this itself
cannot be the problem. Not having awk doesn't seem to be an issue for
compiling the 3.2.1-based driver either (see 1).
Sorry, I'm confused :(
Andi,
from SQLite 3.2.1 to 3.3.5 some automagic in creating opcodes.h and parse.h
has changed significantly. The mkopc3.exe does on Windows what main.mk in
the SQLite source does by using the awk scripts mkopcode{c,h}.awk and
addopcodes.awk. The mkopc3 source in the latest javasqlite is not up to
date and not ready for 3.3.5 (but mkopc3 in the latest ODBC driver is).
You have two options: setup your make of the Java wrapper to use sqlite.dll
or (as in my original tarballs) build SQLite as a link library and link it
directly into sqlite_jni.dll. The former is maybe easier to achieve, the
latter does not require to have sqlite.dll installed in the right place.
Hope that helps,
Christian
Re: [sqlite] PRAGMA table_info
Jackson, Douglas H wrote: This leaves you to parse the DDL from sqlite_master. Doug ... or to correlate 'pragma table_info(tablename)' with 'pragma index_info(tablename)'. Some (unreadable, imperfect) example code can be found in the ODBC driver e.g. in the functions SQLPrimaryKeys(), SQLSpecialColumns(), SQLStatistics(), and the internal function fixupdyncols(). Regards, Christian
Re: AW: [sqlite] [ANN] SQLite ODBC driver version 0.67
[EMAIL PROTECTED] wrote: Hi, I just would like to point out that: - a zip-archive for the drivers (no-install) is not provided That was my intention; is the ZIP version really necessary ? - the documentation for sqliteodbc.c / sqliteodbc.h is missing Ditto, since SQLite 2.* is legacy. The doxygen stuff had a lot of warnings when formatting both SQLite2 and SQLite3 driver sources, therefore I left the legacy one out. If there's really interest in browsable source code for the SQLite2 driver, I'll try to fix it. Regards, Christian
[sqlite] [ANN] SQLite ODBC driver version 0.67
Version 0.67 of the SQLite ODBC driver is ready for download from http://www.ch-werner.de/sqliteodbc It fixes some Unicode length issues with the SQLite 2.8.17 version of the driver and now fully supports binary data. The Win32 version is now made with a MinGW cross compiler and NSIS. Enjoy, Christian
Re: [sqlite] OT: patch for SQLite ODBC
Jarl Friis wrote: How about just setting PRAGMA short_column_names = off PRAGMA full_column_names = on withing SQLColAttribute() and SQLColAttributes() and then, before returning from the function(s), setting it back to PRAGMA short_column_names = on PRAGMA full_column_names = off I'm afraid this will not help. Both SQLColAttribute() and SQLColAttributes() need the presence of a result set with column and table names. This requires either sqlite3_get_table() or sqlite3_prepare()/sqlite3_step() to be already run before these functions. Christian
Re: [sqlite] SQLite Java Wrapper?
majed chatti wrote: I tried to use the SQLite Java Wrapper wich I download froh here http://www.ch-werner.de/javasqlite/ I extract it I do $./configure $make but I have this errors Please try out the new version from the above mentioned website. It should now compile with SQLite versions 3.0.7 up to the latest (and greatest) 3.2.1. Cheers, Christian
[sqlite] ANN: SQLite ODBC Driver 0.65
Hi all, a new version of the SQLite ODBC Driver is available on http://www.ch-werner.de/sqliteodbc An unoptimized driver version supporting SQLite 3.0.7 is included. Best regards, Christian
Re: [sqlite] I need a SQLite3 Wrapper for Java.
[EMAIL PROTECTED] wrote: Hello, and yes I do. I've tried to port, but without success. Please try out http://www.ch-werner.de/javasqlite/javasqlite-20040919.tar.gz Right now (since 3.0.7 is out, big thank you to DRH!) it somewhat began to work on Linux. As usual it is very preliminary experimental pre-alpha and can contain lots of memory leaks and other kinds of bugs. I'd be happy if somebody hacks a Makefile for Windoze. Cheers, Christian
Re: [sqlite] Java
[EMAIL PROTECTED] wrote: Hi, I'm new to SQLite and maybe was this already said, but is there a way to use SQLite inside a Java program? I've found Javasqlite (www.ch-werner.de/javasqlite) which is a JDBC Driver for SQLite but it seems to work with versions SQLite 2.8.13 and this one is not available anymore on the SQLite Website. I've found no Java related entries on the SQLite Website, but it is possible that I missed something. Any help would be appreciated. Thanks a lot The current javasqlite should well compile with SQLite 2.8.15. A version for SQLite 3.x is planned but not ready yet. Regards, Christian
Re: [sqlite] Script perl e python, I can't open database from sqlite
D. Richard Hipp wrote: ... All core features have been thoroughly tested. I'm looking for problems with the API. Do we need new parameters on some functions? Do we need to change the semantics of some functions? Do we need to change the semantics of some of the SQL. ... Please re-introduce the SQLite API function sqlite_libversion() as sqlite3_libversion() in SQLite3. It might be needed for Win32 DLLs. Best regards, Christian
