[sqlite] ODBC driver?
Good morning all, Is there an odbc driver for Sqlite3? It would be useful to be able to use existing data tools... = - The Castles of Dereth Calendar: a tour of that art and architecture of the online game world of Asheron's Call http://www.lulu.com/content/77264 __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
[sqlite] .import function - NULL values
Hi all, How can I import NULL values using the new .import function? The old \N of the COPY statement does not work. How can I escape the separator in the import file? Suppose I want to use ; as a separator then \; does not work. Thanks and regards, T. Rausch __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201
Re: [sqlite] absolute vs. relative path to database on Cygwin
amead writes: > It's a bit of a long-shot, but have you tried the 'cygdrive' path syntax? > > $ sqite /cygdrive/c/cygwn/usr/local/share/refdb/db/refdb > > (assuming you installed Cygwin on C:\cygwin) > Actually I did not try this yet. I'll do so tomorrow, as I don't have any windoze stuff at home (fortunately). My gut feeling says it is going to work. > How did you make it on Windows? I wonder if there is a switch in there > somewhere that is tripping you up. Making is a matter of configure && make. It works like a charm. However, if you closely inspect os.c, you'll notice that the platform-specific code bypasses most of the functionality that Cygwin offers. All file accesses use native Windows calls, and I believe this is why paths with a leading slash fail. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de
Re: [sqlite] absolute vs. relative path to database on Cygwin
Markus Hoenicka wrote: Hi, I've just built 2.8.15 on Cygwin which worked without a hitch (thanks to those who added Cygwin support in the past). However, I came across a problem that makes working with databases a bit inconvenient. It seems like the library does not understand absolute paths, only relative paths. You can simply test this It's a bit of a long-shot, but have you tried the 'cygdrive' path syntax? $ sqite /cygdrive/c/cygwn/usr/local/share/refdb/db/refdb (assuming you installed Cygwin on C:\cygwin) How did you make it on Windows? I wonder if there is a switch in there somewhere that is tripping you up. -Alan -- Alan Mead - [EMAIL PROTECTED] People often find it easier to be a result of the past than a cause of the future.
[sqlite] Feedback from a wrapper writer
These are various issues I had and some suggestions based on writing a Python wrapper for SQLite 3. Overall I was very impressed by the quality of the doc, and of course SQLite 3 itself. Overall the wrapper ended up being just under 3,000 lines of code and provides all the functionality of the C API including the experimental functions. Python supports both a String type (basically char[]) and a Unicode type. I could use the plain or -16 suffix versions of the apis as appropriate. Except that Python can store unicode as UTF16 or as UTF32. Several internal Python functions also put in byte order markers (BOMs). In some cases I have to convert from the String type to Unicode (the encoding of the String type is rarely UTF8) and then for UTF32 strings convert back to UTF8. The SQLite source only copes with UTF16 BOMs, but BOMs exist for UTF8, UTF16, UTF32 and even UTF64. To help get around all this confusion, I suggest another series of APIs for SQLite when dealing with strings. They take a void pointer and the length in bytes. There is also a parameter saying what the encoding is. This encoding is ignored if a BOM is found. I had to use SQLITE_TRANSIENT for all supplied byte data. This is because the pointer I supplied is not the pointer on which the free function needs to be called. The free function needs to be called on the containing object (in my case a PyObject*) of which the pointer is a field. I don't have suggestions for how to improve this since they would just make the code more complicated either for the wrapper writer or the SQLite author. Unfortunately I ended up with four places (two times two) of almost duplicate code. - When implementing user defined functions, I had to convert a sqlite3_value* to a Python type using the sqlite3_value_TYPE functions. For returning results from a row, an sqlite3_value* is not available so I had to use the sqlite3_column_TYPE functions. If possible it would be nice to get a sqlite3_value* for a column (assuming it is stored that way) and then I can use one piece of code for converting from SQLite types to Python types - A similar situation occurs when going from Python types to SQLite types which happens when setting the results of a user defined function and setting bindings, using sqlite3_result_TYPE and sqlite3_bind_TYPE respectively. Being able to allocate a typed sqlite3_value* and then giving that to sqlite3_result/sqlite3_bind would reduce things to one piece of code. It is very hard for me to do garbage collection when a registered function or collation overwrites one of the same name. For example if I register a function "foo" and then register "FOO" I would assume the earlier one is no longer used in SQLite. I currently hold on to my per callback blocks of data until the whole database is closed, since I never know when an earlier function has been release. The simplest solution would be if I could ask SQLite if a particular void*userdata still belongs to any registered function. That way I would know when SQLite is done with it. It would be nice to have an error code allocated for user/wrapper. For example when there is an error in a Python callback, I have to set an error code in SQLite. Currently I just use SQLITE_ERROR but later on it isn't clear who generated that code. If there was something like SQLITE_WRAPPER or SQLITE_USER then it would be unambiguous. The only API I didn't use was sqlite3_collation_needed. It is very difficult to use in a wrapper library since I would have to have a way of tracking from the sqlite3* back to the encapsulating PyObject. I also remain unconvinced of its utility. There are several overlapping ranges of constants. The textual names don't have unique prefixes. For example 2 could be SQLITE_INTERNAL, SQLITE_FLOAT, SQLITE_CREATE_TABLE, SQLITE_IGNORE or one of SQLITE_UTF16BE, SQLITE_UTF16 (the latter two have conflicting definitions in the doc for create_collation and create_function). This makes it somewhat messy converting a number back to a name since you have to be very aware of the context and which textual names are part of which series of constants. For example if I wanted to convert the error code 2 back into the error code name, I can't just find the first name begining with SQLITE_ that has a value of two. If error code names had a unique prefix such as SQLITE_E_ then it would be easy. This issue arises because all the constants share the same name space. In my wrapper you just say apsw.SQLITE_INTERNAL rather than apsw.errors.SQLITE_INTERNAL. Roger
[sqlite] ANN: APSW (Another Python SQLite Wrapper) 3.0.8-r2
APSW (Another Python SQLite Wrapper) 3.0.8-r2 is now available. Download from http://sourceforge.net/project/showfiles.php?group_id=75211_id=113804 Documentation is included in the download and is online at http://www.rogerbinns.com/apsw.html There is an example at the top of the documentation showing Python code using every available feature. APSW provides an SQLite 3 wrapper that provides the thinnest layer over SQLite 3 possible. Everything you can do from the C API to SQLite 3, you can do from Python. Although APSW looks vaguely similar to the DBAPI, it is not compliant with that API and instead works the way SQLite 3 does. This release is a complete wrapper over SQLite 3. In addition to executing queries, you can define your own SQL level functions and collations in Python, have tracers that can help in testing and debugging, use multi-threading with both performance and safety, define busy handlers, show progress and abort queries, and have a true mapping between SQLite's manifest typing and Python types. Roger
[sqlite] ANN: cmucl-sqlite3 (Common Lisp SQLite3 interface)
Good day, I've written a SQLite version 3 interface for CMUCL, which can be found here: http://www.randallsquared.com/download/sqlite/cmucl-sqlite3/ with documentation at: http://www.randallsquared.com/cs-doc.shtml . It automatically caches prepared statements, supports the binding API, and is public domain. -- Randall Randall <[EMAIL PROTECTED]> Property law should use #'EQ , not #'EQUAL .
Re: [sqlite] commas in columns and temporary tables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dennis, | | It won't because the temp tables created by your program ar private to its | database connection. They are not visible through the database connection | opened by sqlite.exe. You can verify this by running two copies of | sqlite.exe in seperate command prompt windows (both looking at the same db | file). You can create permanent tables in one and they will be displayed in | the other, but temp tables will only be displayed by the program that | created them. Aha! That's the other thing I was wondering about... I added a logger to watch which queries were going through and discovered that the TEMPORARY TABLE was being created and also was sticking around. Turns out that I had the wrong column name, and so it was segfaulting. Thanks so much for your help! I really appriciate it :). - -- Taj -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBvdq0qFV3Jf1Ui+IRApvqAJ0e3aUXryQzf0busuNcs9VzUNjvCgCgvQLz pKDWM6CL3LSOk8SCYZy8+xc= =ZsMg -END PGP SIGNATURE-
Re: [sqlite] coding style
Yes but then I must repeat the column names in every query in which I use the view. It is a bug in SQLite, isn't it? Jakub Brass Tilde ([EMAIL PROTECTED]) wrote*: > > > create view myview as select t1.a a from t1 inner join t2 on t1.a=t2.a; > > create table problem as select * from myview; > > Change this last line to: > > create table problem as select a as a from myview; > > That creates the problem table with just "a" as the field name. >
Re: [sqlite] switching off large file support?
Hi, sorry for the noise. Switching off large file support works as advertized. However, "make clean" is not clean enough to remove the previous configuration. Large file support is off if I start from scratch using the compiler switch suggested in os.h. Now I bump into the locking issue that we've been talking about a while ago. I'm using now an all-Unix-style SQLite build on Cygwin, and attempting to access a database results in: SQL error: database is locked Has anyone ever got close to fixing this locking issue on Cygwin? regards, Markus Markus Hoenicka <[EMAIL PROTECTED]> was heard to say: > What surprises me is that it is apparently not possible to switch off large > file > support by using this definition, as suggested by os.h: > -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de
Re: [sqlite] commas in columns and temporary tables
Taj Morton wrote: > http://www.torry.net/db/direct/db_directsql/sqlitedb.zip should work. > Sorry about that. > I will check this out. > No go :(. I used breakpoints and checked right after the first > DB.ExecSQL, then looked at .tables from sqlite.exe...it didn't show up > their either. It won't because the temp tables created by your program ar private to its database connection. They are not visible through the database connection opened by sqlite.exe. You can verify this by running two copies of sqlite.exe in seperate command prompt windows (both looking at the same db file). You can create permanent tables in one and they will be displayed in the other, but temp tables will only be displayed by the program that created them.
[sqlite] switching off large file support?
Hi,
in an attempt to investigate the absolute vs. relative path problem on Cygwin
I've played with a few build possibilities. Interestingly, sqlite now builds
Unix-style on Cygwin, something that failed in the past. This requires the
following definition in Makefile:
TCC = gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I${TOP}/src
i.e. pretty close to what you'd get on any run-of-the-mill Linux or BSD.
However, trying to open a database fails with the following error message:
Unable to open database "sqlitetest": kernel lacks large file support
I understand that this is a limitation of the underlying Windows OS shining
through, so this isn't exactly surprising.
What surprises me is that it is apparently not possible to switch off large file
support by using this definition, as suggested by os.h:
TCC = gcc -g -O2 -DOS_UNIX=1 -DOS_WIN=0 -DSQLITE_DISABLE_LFS -DHAVE_USLEEP=1 -I.
-I${TOP}/src
I still get the same complaint about large file support.
Does anyone know what's going on? Has anyone else attempted to build SQLite
"natively" as a Unix app on Cygwin?
regards,
Markus
--
Markus Hoenicka
[EMAIL PROTECTED]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de
[sqlite] synchronising two databases
Hi all, I have an application where I need to access a database remotely (using TCP/IP). I had thought of just calling sqlite commands (possibly using RPC) and getting database data returned. However, as I will only periodically access the remote database, I need to effectively keep a copy of the database locally for offline number crunching. My question is this: Is it possible for me to copy across the database file and then append it to the end of the locally held database thus synchronizing the two? Is there a better way to do this synchronization? Many thanks in advance, Richard --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.801 / Virus Database: 544 - Release Date: 24/11/04
Re: [sqlite] coding style
> create view myview as select t1.a a from t1 inner join t2 on t1.a=t2.a; > create table problem as select * from myview; Change this last line to: create table problem as select a as a from myview; That creates the problem table with just "a" as the field name.
Re: [sqlite] coding style
Hi all, I have a nasty problem with VIEWs and column names. I create a VIEW by joining two tables. If I use this view to create the table 'problem', the column name "t1.a" appears instead of the expected (and needed) "a". Is it a bug? Do you have an idea how to use the view so as it works? Thanks, Jakub create table t1 (a,b); create table t2 (a,c); insert into t1 values (1,2); insert into t2 values (1,3); create view myview as select t1.a a from t1 inner join t2 on t1.a=t2.a; create table problem as select * from myview;
