Hello:
> That doesn't seem to be explained by all of this discussion.
I have done a simple test and all looks as qorking fine for me.
I have a database created with UTF8 as character set, a single table
with a single field char(1) and the provider looks as being returning a
single character wh
Hello:
> That doesn't seem to be explained by all of this discussion.
I will try to do a test tomorrow to see if something is being done worng
in the provider
-
This SF.net email is sponsored by DB2 Express
Download DB2 Ex
used by why I should have to given what Helen has said.
- Dan.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Helen Borrie
Sent: June 5, 2007 8:13 PM
To: For users and developers of the Firebird .NET providers
Subject: Re: [Firebird-net-provider] Short ch
> > Is "é" a "character"?
>
> Yes. And it is a different character from "e", "ê" or "è".
Obviously, but the character "é" can be represented by the single Unicode
codepoint U+00E9 (aka LATIN SMALL LETTER E WITH ACUTE) or by the sequence
U+0065 U+0301 (aka, LATIN SMALL LETTER E, COMBINING ACU
At 12:26 PM 6/06/2007, you wrote:
> > Which is exactly correct. It's only confusing to those who don't
> > understand that not all characters/character sets encode characters
> > with single-byte encodings.
>
>It's confusing because the "n" represents a buffer size.
The "n" represents _a number_
> Which is exactly correct. It's only confusing to those who don't
> understand that not all characters/character sets encode characters
> with single-byte encodings.
It's confusing because the "n" represents a buffer size. Even allocating
four bytes you cannot store 1 "character" because a chara
At 11:14 AM 6/06/2007, you wrote:
> > YES! Changing the column's type to VARCHAR(1) works.
> >
> > Now can someone tell me why? Doesn't my experience still indicate that
> > there is some sort of bug with columns of type CHAR(1)?
>
>The language spec is a bit confusing with respect to the what the
> YES! Changing the column's type to VARCHAR(1) works.
>
> Now can someone tell me why? Doesn't my experience still indicate that
> there is some sort of bug with columns of type CHAR(1)?
The language spec is a bit confusing with respect to the what the "n"
actually means in CHAR(n). My copy says
At 06:12 AM 6/06/2007, you wrote:
>YES! Changing the column's type to VARCHAR(1) works.
>
>Now can someone tell me why?
You said your data was UTF8 (4-byte characters) and your connection
charset is NONE (which means US ASCII, one-byte characters). ASCII
"D" is stored as "44", while UTF8 "D" is
YES! Changing the column's type to VARCHAR(1) works.
Now can someone tell me why? Doesn't my experience still indicate that there
is some sort of bug with columns of type CHAR(1)?
By the way, I renamed the column back to TYPE and it doesn't seem to cause
any problems.
- Dan.
-Original Messa
Hi,
Can you declare it as a VARCHAR(1)? Or try "select cast(recipt_type as
varchar(1)) from "
Regards.,
...michal
Dan Cooperstock napisał(a):
> Here's a bit more info: I just walked through the execution of "SELECT
> RECEIPT_TYPE FROM RECEIPT WHERE ..." in the debugger, and what happens is
>
ovider@lists.sourceforge.net
Subject: Re: [Firebird-net-provider] Short char field with longer name
OK, I have renamed the column (from TYPE to RECEIPT_TYPE) and I'm still
getting the same error message when I do "select * from tablename":
"Failed to enable constraints. One or mor
OK, I have renamed the column (from TYPE to RECEIPT_TYPE) and I'm still
getting the same error message when I do "select * from tablename":
"Failed to enable constraints. One or more rows contain values violating
non-null, unique or foreign-key constraints."
However, I can execute the same SQL
I changed my connection string to use UTF8 and I'm still getting the same
types of errors. Perhaps I do need to rename this column?
[EMAIL PROTECTED] (Dan Cooperstock) wrote in
news:[EMAIL PROTECTED]:
> So Carlos, are you saying that you don't think that the problem is
> because I have used "Ty
So Carlos, are you saying that you don't think that the problem is because
I have used "Type" as a column name, when it is a reserved word? You think
that should work?
I will try using UTF8 in my connection string and see whether it (a) works
and (b) resolves this problem.
- Dan.
[EMAIL PROTE
Hello:
> I set it to UTF8 when I created the Database. My ConnectionString in my
> program includes "character set=NONE" because as I recall I found (or read)
> that that works best.
That could the reason why you are getting 4 characters, as when using
the NONE character set the provider will
I set it to UTF8 when I created the Database. My ConnectionString in my
program includes "character set=NONE" because as I recall I found (or read)
that that works best.
Thanks - Dan.
[EMAIL PROTECTED] (Carlos Guzmán Álvarez) wrote in
news:[EMAIL PROTECTED]:
> Hello:
>
>
> What character se
Hello:
> I just looked it up, and you are right. It is a reserved word. However,
> that doesn't exactly explain why "Select Type from TableName" does work,
> except for always returning 4 characters instead of 1. It returns the
> correct data from the field (one character), just padded with 3 s
I just looked it up, and you are right. It is a reserved word. However,
that doesn't exactly explain why "Select Type from TableName" does work,
except for always returning 4 characters instead of 1. It returns the
correct data from the field (one character), just padded with 3 spaces on
the ri
ird-net-provider@lists.sourceforge.net
> Subject: [Firebird-net-provider] Short char field with longer name
> returns padded
>
> I have a field in a table named Type, and declared as Char(1). What I'm
> finding is that when I retrieve that column with a SELECT, the result
> i
I have a field in a table named Type, and declared as Char(1). What I'm
finding is that when I retrieve that column with a SELECT, the result is
padded to the length of the field name (e.g. 4 chars, the length of
"Type").
This causes serious problems, for instance if I do "SELECT Type from
Tab
21 matches
Mail list logo
