Re: [sqlite] Possible bug with non-standard characters in column names

2006-05-11 Thread Micha Bieber
Thursday, May 11, 2006, 09:36:17, Preston & Chrystie wrote:

> if your first statement after creating the database is:
> PRAGMA encoding = "UTF-16";

> then the error you get is slightly different:
sqlite>> ALTER TABLE test1 ADD straße VARCHAR(255);
> SQL error: malformed database schema - near "(": syntax error

> I was hoping that would fix it for you.. guess not, but at least you
> know of the potential error sooner rather than later...tried the
> column name in quotes too.. didn't help.

> --preston


> On 5/10/06, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> Not sure- I've tried this through JDBC and the command line
>> client, I'm not a developer at that level :(
>>
>> Thanks,
>> Andreas
>>
>> -Original Message-
Why not using simply 'Strasse'. I'm german too. IMO, the most
hassle-free way doing these things lies in avoiding encoding issues, if
you can do so. A database is often a 'hidden layer', a good interface
should be able to transform potentially visible parts into something
more perfect (like 'Straße' for an UI).

Micha  
-- 



Re: [sqlite] Possible bug with non-standard characters in column names

2006-05-11 Thread Preston & Chrystie

if your first statement after creating the database is:
PRAGMA encoding = "UTF-16";

then the error you get is slightly different:
sqlite> ALTER TABLE test1 ADD straße VARCHAR(255);
SQL error: malformed database schema - near "(": syntax error

I was hoping that would fix it for you.. guess not, but at least you
know of the potential error sooner rather than later...tried the
column name in quotes too.. didn't help.

--preston


On 5/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Not sure- I've tried this through JDBC and the command line client, I'm not a 
developer at that level :(

Thanks,
Andreas

-Original Message-
From: Clay Dowling [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 10. Mai 2006 18:42
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Possible bug with non-standard characters in column names


[EMAIL PROTECTED] said:
> CREATE TABLE test1 (loader_id INTEGER PRIMARY KEY, loader_status
> VARCHAR(255)); ALTER TABLE test1 ADD name VARCHAR(255); ALTER TABLE
> test1 ADD straße VARCHAR(255); ALTER TABLE test1 ADD plz VARCHAR(255);
>
> Raises an SQL error: malformed database schema - near "plz": syntax
> error
>
> The suspected bug is that the ALTER TABLE that adds straße should
> raise the error, not the following statement?

I'm guessing that "straße" was indeed what ticked off the engine, but it took until 
"plz" for the parser to realize the problem.  Have you tried using the 16 bit character 
functions instead?  The 8 bit functions could be choking on the essen.

Clay Dowling
--
Simple Content Management
http://www.ceamus.com



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.



RE: [sqlite] Possible bug with non-standard characters in column names

2006-05-10 Thread andreas.goetz
Not sure- I've tried this through JDBC and the command line client, I'm not a 
developer at that level :(

Thanks,
Andreas

-Original Message-
From: Clay Dowling [mailto:[EMAIL PROTECTED] 
Sent: Mittwoch, 10. Mai 2006 18:42
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Possible bug with non-standard characters in column names


[EMAIL PROTECTED] said:
> CREATE TABLE test1 (loader_id INTEGER PRIMARY KEY, loader_status 
> VARCHAR(255)); ALTER TABLE test1 ADD name VARCHAR(255); ALTER TABLE 
> test1 ADD straße VARCHAR(255); ALTER TABLE test1 ADD plz VARCHAR(255);
>
> Raises an SQL error: malformed database schema - near "plz": syntax 
> error
>
> The suspected bug is that the ALTER TABLE that adds straße should 
> raise the error, not the following statement?

I'm guessing that "straße" was indeed what ticked off the engine, but it took 
until "plz" for the parser to realize the problem.  Have you tried using the 16 
bit character functions instead?  The 8 bit functions could be choking on the 
essen.

Clay Dowling
--
Simple Content Management
http://www.ceamus.com



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.


Re: [sqlite] Possible bug with non-standard characters in column names

2006-05-10 Thread Clay Dowling

[EMAIL PROTECTED] said:
> CREATE TABLE test1 (loader_id INTEGER PRIMARY KEY, loader_status
> VARCHAR(255));
> ALTER TABLE test1 ADD name VARCHAR(255);
> ALTER TABLE test1 ADD straße VARCHAR(255);
> ALTER TABLE test1 ADD plz VARCHAR(255);
>
> Raises an SQL error: malformed database schema - near "plz": syntax error
>
> The suspected bug is that the ALTER TABLE that adds straße should raise
> the error, not the following statement?

I'm guessing that "straße" was indeed what ticked off the engine, but it
took until "plz" for the parser to realize the problem.  Have you tried
using the 16 bit character functions instead?  The 8 bit functions could
be choking on the essen.

Clay Dowling
-- 
Simple Content Management
http://www.ceamus.com



[sqlite] Possible bug with non-standard characters in column names

2006-05-10 Thread andreas.goetz

Creating a table like this:

CREATE TABLE test1 (loader_id INTEGER PRIMARY KEY, loader_status VARCHAR(255));
ALTER TABLE test1 ADD name VARCHAR(255);
ALTER TABLE test1 ADD straße VARCHAR(255);
ALTER TABLE test1 ADD plz VARCHAR(255);

Raises an SQL error: malformed database schema - near "plz": syntax error

The suspected bug is that the ALTER TABLE that adds straße should raise the 
error, not the following statement?

Cheers,
Andreas

Andreas Goetz
Accenture
Communications & High Tech
cell +49 175 576 2383
[EMAIL PROTECTED]


This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.