Pablo,
Using a Digest Number as your message subject is a good way to get your
message ignored. When replying to a Digest entry, please paste the
original subject.

At 10:36 AM 23/07/2003 -0300, you wrote:

>First: thanks for answering.
>Yes, I didn't define the charset when I created the databsae, but isn't this
>way suppose to make the database accept any character ?

Character set NONE will accept any byte and write it to the database as a
character. The problem comes then, when reading it. If any character is
not in the US Ascii character set, it will throw a transliteration error
because it doesn't know what to do with it.

>And if I define a specific field to a specific charset, shouldn't it work ?

It won't work if the client application stores characters from a different
charset, or if the client library doesn't tell the server what character
set the data is supposed to belong to.

>And besides the definition I gave, isn't a database engine supose to allow
>updates and deletes of any data wich where allow to be inserted ?

Not if the data are of the wrong kind. Strings in databases that support
character sets are not just strings - they are "strings with attitude". If
the charsets don't match, then the data don't match.

>How come I
>can insert a character in a VARCHAR field but I can't perform updates or
>deletes over it? What could I have done to achive such a behavior of the
>engine ?

A mismatch between the charset of the stored data and the charset of the
search or update data will always cause this.

>About the connection, I don't know how to define the charset within it. Do
>you know how can I accomplish that using Visual Fox Pro Views through a File
>DSN ? Would "SET NAME" help ?

I can't answer that for VFP, but you should be able to get some clues by
looking up the documentation for the ODBC driver you are using, to see how
it implements either 'SET NAMES <character set name>' or the database
parameter buffer (DPB) parameter isc_dpb_lc_ctype.

heLen