Subject | Re: [IBO] Unable to Edit/Save BLOB Text with IBO + Infopower (they referred me here) |
---|---|
Author | Helen Borrie |
Post date | 2004-01-27T00:01Z |
At 02:57 PM 26/01/2004 -0800, you wrote:
don't define one at all unless you plan to write ESQL applications. It
will be 80 bytes by default and FB will ignore it anyway. IBO streams
blobs and the server decides, all by itself, what size segment to store,
regardless of *what* is defined in the domain. (But I'm curious why you
have to guess this - don't you have a way to look at your metadata?)
sets (as I don't when writing quick and dirty demos). You're getting these
transliteration messages because you defined WIN1251 as DEFAULT CHARACTER
SET WIN1251 for the database but ignored the character set attribute at the
client. You have to set that in your TIB_Connection's CharSet property, to
match the db's default charset.
DEFAULT CHARACTER SET clause, it defaults to NONE. NONE will accept any
streams of bytes and treat them all as one-byte characters. The only
characters it "knows about" are the US ASCII set, so it has no mappings to
uppercase or match characters that are outside that set. That's why you
have to have a default character set just about anywhere in the world
except the USA (where people often don't care about correct spelling of
foreign names, etc.) and maybe Australia (where I've noticed a similar lack
of concern to spell foreign names correctly).
Helen
>The BLOB Text segment size was set at 15 not 80. I was using a FB managerGoodness knows why. The segment size really doesn't matter in DSQL. Just
>which
>I guess created a Domain with a default size of 15?
don't define one at all unless you plan to write ESQL applications. It
will be 80 bytes by default and FB will ignore it anyway. IBO streams
blobs and the server decides, all by itself, what size segment to store,
regardless of *what* is defined in the domain. (But I'm curious why you
have to guess this - don't you have a way to look at your metadata?)
>Anyway, when changing that,Well, it only solves the problem if you don't need to care about character
>suddenly, I could start editing and saving edits to text blob fields again.
>That's it. I knew it was something basic!
>
>Also, Daniel, when I was trying to set up a demo for you, I kept running into
>problems with creating a DB with charset of WIN1251 and something about
>Firebird.msg/truncating data, etc. I changed back to charset of NONE (in other
>forum messages this was said to be incorrect? i.e. one should always
>define the default charset.) and that solved that problem.
sets (as I don't when writing quick and dirty demos). You're getting these
transliteration messages because you defined WIN1251 as DEFAULT CHARACTER
SET WIN1251 for the database but ignored the character set attribute at the
client. You have to set that in your TIB_Connection's CharSet property, to
match the db's default charset.
> I noticed in Helen's demo andNONE is a character set. When you do CREATE DATABASE and don't include a
>likewise in the FB QSG, that there is no default charset set when creating a
>database.
DEFAULT CHARACTER SET clause, it defaults to NONE. NONE will accept any
streams of bytes and treat them all as one-byte characters. The only
characters it "knows about" are the US ASCII set, so it has no mappings to
uppercase or match characters that are outside that set. That's why you
have to have a default character set just about anywhere in the world
except the USA (where people often don't care about correct spelling of
foreign names, etc.) and maybe Australia (where I've noticed a similar lack
of concern to spell foreign names correctly).
Helen