On 8/4/06, Trevor Talbot <[EMAIL PROTECTED]> wrote:
On 8/4/06, Cory Nelson <[EMAIL PROTECTED]> wrote:
> But, since you brought it up - I have no expectations of SQLite
> integrating a full Unicode locale library, however it would be a great
> improvement if it would respect the current locale
On 8/4/06, Cory Nelson <[EMAIL PROTECTED]> wrote:
But, since you brought it up - I have no expectations of SQLite
integrating a full Unicode locale library, however it would be a great
improvement if it would respect the current locale and use wcs*
functions when available, or at least order by
On 8/5/06, Cory Nelson <[EMAIL PROTECTED]> wrote:
On 8/4/06, Nuno Lucas <[EMAIL PROTECTED]> wrote:
> On 8/4/06, Cory Nelson <[EMAIL PROTECTED]> wrote:
> > IE, using memcmp() to compare strings. I've been bitten by this
> > before, with SQLite producing unexpected results when using UTF-8.
> >
On 8/4/06, Nuno Lucas <[EMAIL PROTECTED]> wrote:
On 8/4/06, Cory Nelson <[EMAIL PROTECTED]> wrote:
> IE, using memcmp() to compare strings. I've been bitten by this
> before, with SQLite producing unexpected results when using UTF-8.
> Using UTF-16 has worked more reliably in my experience.
On 8/4/06, Cory Nelson <[EMAIL PROTECTED]> wrote:
IE, using memcmp() to compare strings. I've been bitten by this
before, with SQLite producing unexpected results when using UTF-8.
Using UTF-16 has worked more reliably in my experience.
SQLite only knows how to sort ASCII, so memcmp does that
On 8/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
SQLite never has to figure out if the value in a field is a date
or a time. There is no way for it to determine this.
Woops. I guess I thought it did. Sorry for the confusion.
On Fri, 04 Aug 2006 14:42:01 +0200, you wrote:
>[EMAIL PROTECTED] wrote:
[...]
>>And it would go against the
>>basic philosophy of SQLite.
>>
>>
>in which way?
>
>but as far as I am concerned, I'll be happy if I can get the original
>type declaration for the column by querying the database.
"Will Leshner" <[EMAIL PROTECTED]> wrote:
> On 8/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > Adding DATE and TIMEINTERVAL types to SQLite would require an
> > incompatible file format change. And it would go against the
> > basic philosophy of SQLite.
>
> I wonder if it might not
On 8/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
"Cory Nelson" <[EMAIL PROTECTED]> wrote:
> On 8/3/06, RohitPatel <[EMAIL PROTECTED]> wrote:
>
> I recommend using utf-16 in the database - sqlite doesn't fully
> support utf-8, and some things may give unexpected results if you use
>
On 8/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Adding DATE and TIMEINTERVAL types to SQLite would require an
incompatible file format change. And it would go against the
basic philosophy of SQLite.
I wonder if it might not be useful to be able to ask SQLite if a value
is a date or
On 8/3/06, Cory Nelson <[EMAIL PROTECTED]> wrote:
I recommend using utf-16 in the database - sqlite doesn't fully
support utf-8, and some things may give unexpected results if you use
it.
As with others who have replied, I have not had a problem working with
UTF8 in a SQLite database.
Alexander Lamb <[EMAIL PROTECTED]> wrote:
> Well, I am afraid it didn't work.
>
> Somehow, the legacy_file_format info is not "sticky".
>
The "legacy_file_format" pragma does not appear to be
sticky, but it is. The value reported back by
PRAGMA legacy_file_format
is incorrect. But the
Alexander Lamb wrote:
Well, I even tried to insert a row in the table. The table contains
the data. The file on the disk is 2K length. The PRAGMA commands tells
me I am in legacy file format mode (1) but when I quit then
return, I am back to 0!
I just tried the same thing and got
Alexander Lamb uttered:
Well, sorry, but I did exactly that:
1) When I do the PRAGMA command the file is created (I can see it
appearing in the explorer)
2) After the create table, if I do PRAGMA legacy_file_format; I
indeed receive "1" as an answer.
However,
I ".quit" then go back
Alexander Lamb uttered:
Well, sorry, but I did exactly that:
1) When I do the PRAGMA command the file is created (I can see it appearing
in the explorer)
2) After the create table, if I do PRAGMA legacy_file_format; I indeed
receive "1" as an answer.
However,
I ".quit" then go back into
Well, sorry, but I did exactly that:
1) When I do the PRAGMA command the file is created (I can see it
appearing in the explorer)
2) After the create table, if I do PRAGMA legacy_file_format; I
indeed receive "1" as an answer.
However,
I ".quit" then go back into the database and ask
Alexander Lamb <[EMAIL PROTECTED]> writes:
> 1. (*) text/plain
>
> Well, I am afraid it didn't work.
>
> Somehow, the legacy_file_format info is not "sticky".
>
> I did:
>
> sqlite3
>
> then in command mode:
>
> PRAGMA legacy_file_format=ON;
>
> then
>
> ATTACH "d:\mydb.db" AS mydb;
Well, I am afraid it didn't work.
Somehow, the legacy_file_format info is not "sticky".
I did:
sqlite3
then in command mode:
PRAGMA legacy_file_format=ON;
then
ATTACH "d:\mydb.db" AS mydb;
then
CREATE TABLE TEST (id int);
if I then quit and return to sqlite3 and attach the database I
Ahah, I understood "PRAGMA" as an compile option :-(
That's why point 2 was not very clear (I am new to SQLite).
I'll do this right away!
Thanks,
Alex
--
Alexander Lamb
[EMAIL PROTECTED]
On Aug 4, 2006, at 3:27 PM, Gerry Snyder wrote:
Alexander Lamb wrote:
So it is not possible to create
Alexander Lamb wrote:
So it is not possible to create a database with the legacy file format
using the command line on Windows and SQLite 3.3?
Yes it is. Reread Dr. Hipp's point (2) below.
If I understand correctly, I need to grab the latest CVS version of
SQLite to have the 3.3 format
[EMAIL PROTECTED] wrote:
Adding DATE and TIMEINTERVAL types to SQLite would require an
incompatible file format change.
well, yes, that was already clear. but: where is the type of the data
being stored? aren't there a few spare bits to use for 'future
additions', that is, new data
So it is not possible to create a database with the legacy file
format using the command line on Windows and SQLite 3.3?
If I understand correctly, I need to grab the latest CVS version of
SQLite to have the 3.3 format disabled by default.
The problem I see with that is that I am not a
Simply using SMB (mount from my mac to the PC) then a finder copy.
--
Alexander Lamb
[EMAIL PROTECTED]
On Aug 4, 2006, at 10:31 AM, Brandon, Nicholas (UK) wrote:
I did the test with two versions of SQLite on Windows: with the
3.3 it
doesn't work (which seems more or less
normal
Cory Nelson wrote:
I recommend using utf-16 in the database - sqlite doesn't fully
support utf-8, and some things may give unexpected results if you use
it.
Could you expand a bit on this please?
I haven't seen any bugs as such with sqlite as such but I did have a few
problems storing
Alexander Lamb <[EMAIL PROTECTED]> wrote:
> Hello list (I am new but searched a bit before posting).
>
> I am trying to convert an Access database on WindowsXP to an SQLite
> database to be used in a CoreData application on MacOSX (BTW, this
> task seems so generic and would help so much in
Mario Frasca <[EMAIL PROTECTED]> wrote:
>
> would it be difficult, or simply impossible, to implement these types in
> sqlite?
>
Adding DATE and TIMEINTERVAL types to SQLite would require an
incompatible file format change. And it would go against the
basic philosophy of SQLite.
--
D. Richard
"Cory Nelson" <[EMAIL PROTECTED]> wrote:
> On 8/3/06, RohitPatel <[EMAIL PROTECTED]> wrote:
>
> I recommend using utf-16 in the database - sqlite doesn't fully
> support utf-8, and some things may give unexpected results if you use
> it.
>
Oh really? What exactly is missing from SQLite's
Nuno Lucas wrote:
You need to get the column declared type and convert it to the type
you want based on that.
mmm... so I would look at it in a statically typed way. it sounds
reasonable and is surely acceptable for me. but: how do I get the
declared type of the column? currently the
On 8/4/06, Mario Frasca <[EMAIL PROTECTED]> wrote:
nice. if I was just working inside of SQL and was only interested in printing
the values, it would probably be fine. my problem is that I'm co-author of a
python library (http://ibo.sourceforge.net) on top of various db-api2 interface
On 8/4/06, Cory Nelson <[EMAIL PROTECTED]> wrote:
I recommend using utf-16 in the database - sqlite doesn't fully
support utf-8, and some things may give unexpected results if you use
it.
Could you give some example of unexpected result with UTF-8?
In my experience the only unexpected results
>I did the test with two versions of SQLite on Windows: with the 3.3 it
doesn't work (which seems more or less
>normal according to the documentation).
>However, with version 2.8, the mac can't read the file. The error is:
>Error: file is encrypted or is not a database
How have you
Hello list (I am new but searched a bit before posting).
I am trying to convert an Access database on WindowsXP to an SQLite
database to be used in a CoreData application on MacOSX (BTW, this
task seems so generic and would help so much in transfering legacy
Access apps to MacOSX I am
Dennis Cote wrote:
Mario Frasca wrote:
where I would expect:
sqlite> select datetime('now');
2006-08-03 11:36:32.211032
sqlite> select typeof(datetime('now'));
datetime
sqlite> select datetime('now') - date('2006-01-01');
214 11:36:51.291331
sqlite> select typeof(datetime('now') -
33 matches
Mail list logo
