[sqlite] v2 - v3 upgrade

2005-01-21 Thread Drew, Stephen
Hello, I'm trying to upgrade my wrapper library for SQLite to use version 3. Everything is going well so far, with one exception. In Version 2.x, I would use the data type string which is returnedafter the column names in call to sqlite_step(). This allowed me to distinguish dates from

Re: [sqlite] v2 - v3 upgrade

2005-01-21 Thread Will Leshner
On Fri, 21 Jan 2005 14:30:01 -, Drew, Stephen [EMAIL PROTECTED] wrote: However, with version 3 and its new data types, I can't seem to be able to replicate this. It seems as though it will just be treated as a numeric data type. Does anyone know how I can achieve the same functionality?

RE: [sqlite] v2 - v3 upgrade

2005-01-21 Thread Drew, Stephen
Will, Thanks for the reply. Yes in version 2 I would do something like: CREATE TABLE TEST (d DATE); And use the DATE returned in the column names (using the show datatypes pragma). From the documentation, it appears that sqlite3_column_type returns one of five defined types, none of which is a

Re: [sqlite] v2 - v3 upgrade

2005-01-21 Thread Will Leshner
On Fri, 21 Jan 2005 15:59:36 -, Drew, Stephen [EMAIL PROTECTED] wrote: Will, From the documentation, it appears that sqlite3_column_type returns one of five defined types, none of which is a date (obviously, as SQLite doesn't distinguish dates). Is there a way I can continue using the

[sqlite] Bare btree.c usage...

2005-01-21 Thread Joseph Stewart
Hello all, Was there a discussion on this list about using the btree layer? I've searched the list and can't find the messages I *think* I remember. What I *think* I remember is someone sharing a shell of how to use the btree stuff standalone. I apologize in advance for not looking closer at

[sqlite] A question about the mailing list archive...

2005-01-21 Thread Joseph Stewart
Is there anyplace to download the mailing list archive in mbox format? -joe -- Person who say it cannot be done should not interrupt person doing it. -- Old Scottish Proverb

[sqlite] Version 3.1.0

2005-01-21 Thread D. Richard Hipp
Version 3.1.0 (alpha) of SQLite is now available on the website. Release notes are available from a link on the homepage. This released is labeled alpha but it is still very well tested. By being alpha it means that there is still a small window of opportunity during when users can suggest API

Re: [sqlite] Version 3.1.0

2005-01-21 Thread Cory Nelson
Any API changes? On Fri, 21 Jan 2005 13:33:35 -0500, D. Richard Hipp [EMAIL PROTECTED] wrote: Version 3.1.0 (alpha) of SQLite is now available on the website. Release notes are available from a link on the homepage. This released is labeled alpha but it is still very well tested. By being

Re: [sqlite] Version 3.1.0

2005-01-21 Thread Eli Burke
D. Richard Hipp wrote: This released is labeled alpha but it is still very well tested. By being alpha it means that there is still a small window of opportunity during when users can suggest API changes. Once we go to beta (in about a week) no more changes will be accepted. So if you want to

Re: [sqlite] Version 3.1.0 API suggestion: sqlite3_commit()

2005-01-21 Thread Eric Scouten
D. Richard Hipp wrote: This released is labeled alpha but it is still very well tested. By being alpha it means that there is still a small window of opportunity during when users can suggest API changes. Once we go to beta (in about a week) no more changes will be accepted. So if you want to

AW: [sqlite] Version 3.1.0

2005-01-21 Thread Michael Ruck
You could replace the const void* with wchar_t on conforming compilers (such as MCVC 6+) to simplify unicode development: #if defined(wchar_t) typedef const wchar_t* strw; #else // #if defined(wchar_t) typedef const void* strw; #endif // #if defined(wchar_t) I think this would allow easier usage

Re: [sqlite] Version 3.1.0 API suggestion: sqlite3_commit()

2005-01-21 Thread Ulrik Petersen
Eric, Eric Scouten wrote: D. Richard Hipp wrote: This released is labeled alpha but it is still very well tested. By being alpha it means that there is still a small window of opportunity during when users can suggest API changes. Once we go to beta (in about a week) no more changes will be

[sqlite] Re Version 3.1

2005-01-21 Thread Pascal Van Puymbroeck
Perhaps you can include the '.lib' file together with the dll and '.def' file in the windows version, for I use the codewarrior from Metrowerks. Besides, I've noticed that there are a lot of implicit castings from char * to unsigned char * which are not accepted when I try to compile the

Re: [sqlite] Version 3.1.0

2005-01-21 Thread Doug Currie
Friday, January 21, 2005, 1:33:35 PM, DRH wrote: Version 3.1.0 (alpha) of SQLite is now available on the website. Compiling with MinGW MSYS on WinXP... 1. I had to modify my lib/tclConfig.sh to have TCL_LIB_SPEC='-L/mingw/lib -ltcl84' instead of TCL_LIB_SPEC='' or else testfixture wouldn't

Re: [sqlite] Version 3.1.0

2005-01-21 Thread Raymond Irving
Hi, It would be nice if Autovacum can be set for a database with data and also be set to occur at timely intervals. Maybe something like every 1000 updates or deletes. __ Raymond Irving --- D. Richard Hipp [EMAIL PROTECTED] wrote: Version 3.1.0 (alpha) of SQLite is now available on the

Re: AW: [sqlite] Version 3.1.0

2005-01-21 Thread Tom
Hello, wchar_t is not a 2 byte unicode character. For example, in Mac OS X, wchar_t is 4 bytes. It would be better to define UniChar as 2 byte type. In OS X it is defined as: typedef UInt16 UniChar; where UInt16 is defined (on most, if not all platforms) as: typedef unsigned short UInt16; Tom

Re: [sqlite] Version 3.1.0 API suggestion: sqlite3_commit()

2005-01-21 Thread Eric Scouten
Ulrik Petersen wrote: Eric, Eric Scouten wrote: D. Richard Hipp wrote: This released is labeled alpha but it is still very well tested. By being alpha it means that there is still a small window of opportunity during when users can suggest API changes. Once we go to beta (in about a week) no

Fw: [sqlite] Version 3.1.0 API suggestion: autovacuum

2005-01-21 Thread =?iso-8859-1?Q?Miguel_Angel_Latorre_D=EDaz?=
What if the autovacuum feature could be set based on a percent (pragma autovacuum_percent?) of the unused file size (if known) ? It could be useful to specify the fullness of data/keys of pages (pragma table_full_percent?), this way an almost-readonly table could use the full 100% of the page. So

Re: [sqlite] Re Version 3.1

2005-01-21 Thread Cory Nelson
A .lib is usually limited to one line of compilers - the .def allows you to generate a .lib. IMHO it would be a waste of space in the .zip for many people. On Fri, 21 Jan 2005 21:13:20 +0100, Pascal Van Puymbroeck [EMAIL PROTECTED] wrote: Perhaps you can include the '.lib' file together with

Re: [sqlite] Version 3.1.0

2005-01-21 Thread Dennis Cote
Doug Currie wrote: Friday, January 21, 2005, 1:33:35 PM, DRH wrote: Version 3.1.0 (alpha) of SQLite is now available on the website. Compiling with MinGW MSYS on WinXP... 1. I had to modify my lib/tclConfig.sh to have TCL_LIB_SPEC='-L/mingw/lib -ltcl84' instead of TCL_LIB_SPEC='' or else

[sqlite] 3.1 vs. 3.0 file compatibility.

2005-01-21 Thread bbum
Under what circumstances is a file written by 3.1 incompatible with a file written by 3.0? thanks, b.bum smime.p7s Description: S/MIME cryptographic signature

Re: [sqlite] Version 3.1.0

2005-01-21 Thread Dan Kennedy
--- Doug Currie [EMAIL PROTECTED] wrote: Friday, January 21, 2005, 1:33:35 PM, DRH wrote: Version 3.1.0 (alpha) of SQLite is now available on the website. Compiling with MinGW MSYS on WinXP... 1. I had to modify my lib/tclConfig.sh to have TCL_LIB_SPEC='-L/mingw/lib -ltcl84'

Re: [sqlite] Re Version 3.1

2005-01-21 Thread Dennis Cote
Pascal Van Puymbroeck wrote: Perhaps you can include the '.lib' file together with the dll and '.def' file in the windows version, for I use the codewarrior from Metrowerks. Besides, I've noticed that there are a lot of implicit castings from char * to unsigned char * which are not accepted when

Re: [sqlite] 3.1 vs. 3.0 file compatibility.

2005-01-21 Thread Dan Kennedy
If the 3.1 file is created with the auto-vacuum option enabled (PRAGMA auto_vacuum = 1;), then the database will appear read-only to 3.0 clients. That's the only incompatibility. --- [EMAIL PROTECTED] wrote: Under what circumstances is a file written by 3.1 incompatible with a file written

Re: [sqlite] 3.1 vs. 3.0 file compatibility.

2005-01-21 Thread D. Richard Hipp
On Fri, 2005-01-21 at 14:38 -0800, [EMAIL PROTECTED] wrote: Under what circumstances is a file written by 3.1 incompatible with a file written by 3.0? When the database uses features that 3.0 does not support. For example, if a VIEW definition uses the new EXISTS operator, an older 3.0

Re: [sqlite] 3.1 vs. 3.0 file compatibility.

2005-01-21 Thread bbum
On Jan 21, 2005, at 2:49 PM, Dan Kennedy wrote: If the 3.1 file is created with the auto-vacuum option enabled (PRAGMA auto_vacuum = 1;), then the database will appear read-only to 3.0 clients. That's the only incompatibility. OK -- can auto-vacuum be turned on within a database that was created

Re: [sqlite] 3.1 vs. 3.0 file compatibility.

2005-01-21 Thread Dan Kennedy
--- [EMAIL PROTECTED] wrote: On Jan 21, 2005, at 2:49 PM, Dan Kennedy wrote: If the 3.1 file is created with the auto-vacuum option enabled (PRAGMA auto_vacuum = 1;), then the database will appear read-only to 3.0 clients. That's the only incompatibility. OK -- can auto-vacuum be

[sqlite] tcl_install ignores DESTDIR

2005-01-21 Thread bbum
The 'tcl_install' target of Makefile.in ignores the DESTDIR that may have been specified as a part of the build. The tclinstaller.tcl script should install the sqlite3 tcl hook in DESTDIR/LIBDIR such that a build-for-packaging doesn't inadvertently shove things into the installed system. The

[sqlite] LOWER() and Data Types

2005-01-21 Thread David Wheeler
SQLiters, First of all: Rocking great RDBMS. I love it! Now, to my question. I'm confused about the typelessness of SQLite, because I've found a place where the type *does* seem to matter. This example demonstrates the issue: sqlite create table foo (age int); sqlite insert into foo values (7);

Re: [sqlite] Version 3.1.0

2005-01-21 Thread John Richard Moser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd probably suggest something about how to set BLOB data from a void* and an int in 1 line of code, if I had any idea at all how blob data is set now. I found an example, but it was something like 400 lines long, overly complex (loading a blob into

Re: [sqlite] Version 3.1.0

2005-01-21 Thread Greg Miller
Robert L Cochran wrote: I should have indicated in my earlier post that magazines which do side-by-side hardware testing are saying that the AMD Athlon 64 is indeed faster than the Pentium 4; for example look in the January issue of Maximum PC magazine. they have a followup test supplementing

Re: [sqlite] Version 3.1.0

2005-01-21 Thread Roger Binns
I think all this discussion has missed the original question. Quite simply, is there any way in which the SQLite *source code* could be changed in order to get better performance on 64 bit machines. If there is then following questions should be answered: - Has it already been done (or should

Re: [sqlite] Version 3.1.0

2005-01-21 Thread Doug Currie
Friday, January 21, 2005, 5:41:00 PM, Dan wrote: autovacuum-ioerr2.4.0... Error: error copying test.db to backup.db: no such file or directory autovacuum-ioerr2-4.1.1... Error: error copying backup.db to test.db: no such file or directory autovacuum-ioerr2-4.1.2... Ok

[sqlite] SQLite and PHP5 tomorrow

2005-01-21 Thread Andrea Giammarchi
Hi everybody, I'm veiwing that SQLite has new and updated versions every few months, you are doing a very good work but I wonder if next release oh PHP5 ( 5.0.1 ) will has at least version 3.0 of this wonderful database engine :-) Regards, Andrea Giammarchi -- No virus