[Firebird-devel] [Bug #112177] error with non-english column defaults

[<no...@so...>]

Bug #112177, was updated on 2000-Aug-17 10:02
Here is a current snapshot of the bug.

Project: Firebird
Category: Core Engine
Status: Open
Resolution: None
Bug Group: Confirmed
Priority: 9
Submitted by: andreik
Assigned to : patrickgriffin
Summary: error with non-english column defaults

Details: hi,

I just discovered error in IB6.0.

I have a table

create table bug_bugbase (
  s varchar(20) character set win1251 collate win1251 default 'XXXX'
    not null
);

I work in win1251 code page, which is for belarusian language.

Note, the default value above 'XXXX' is a cyrrilic (belarusian) text.

Database works well, I can insert records, update, and delete them.
But when I backup it and then restore I receive the next error
message from gbak:

gbak: restore failed for record in table BUG_BUGBASE
gbak: ERROR: arithmetic exception, numeric overflow, or string truncation
gbak: ERROR:     Cannot transliterate character between character sets

it seems that IB supports default values only in standart
(english) code page.

I'm very upset, because, I just lost result of week of my work.
I backed up database, then deleted GDB file and then
tried to restore it and recieved this message. All records in tables
where I had default values in cyrrilic are missed.

With best regrads,

Andrei Kireev
a_k...@ya...






Follow-Ups:

Date: 2000-Dec-10 13:29
By: robocop

Comment:
Esoft wrote:
«The problem is FB cannot use collation conversion if one of the field have
no collation at all.»

If you look at the rules for collations posted by Diane Brown in Mers list,
you will see that in this respect, IB is behaving near the standard. Using
a mixture of collations follows a set of rules.

C.

-------------------------------------------------------

Date: 2000-Dec-10 04:48
By: esoft

Comment:
Firebird does a lot of weird things with the collation stuff. I'm involved
developing a firebird based application server and we've lost a lot of time
with collation problems. We've solved almost all of them right now but I'm
plainning to get a draconian solution to and storing all the localizated
checks DB's objects to a table and referencing through in a application
level. The problem is FB cannot use collation conversion if one of the
field have no collation at all... and I think there are system tables where
this rule is affected whatever your tables collation is.

Anyway, the Andrei's problem is one I solved with the next rules:

* Use the charset clause when creating your database.

* Don't specify a charset in your connection to alter, create other DB
structures. The database's default charset should be used automatically...
but you'll experiment problem if you explicitly specify that.

* Specify a charset whenever you gonna do a data modification (INSERT,
UPDATE).

These rules have force me to create two DB connections.. one for data
retrieval and another one for data modification... reallly sux.. but
workarounds all the collation wasting.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112177&group_id=9028