Subject | Re: [firebird-support] Re: Corrupt database |
---|---|
Author | Helen Borrie |
Post date | 2004-04-30T23:38:23Z |
At 06:39 PM 30/04/2004 -0400, you wrote:
You get (first) the error message associated with the SQLCODE, followed by (if applicable) the message associated with the GDSCODE. The idea is that you can trap the high-level or the low-level exception, according to need. It's not a propos for this group of exceptions, since the transliteration error can't be solved by attacking any of the problems listed by the high-level message.
Transliteration errors happen under one or more of the following conditions:
** The connection character set and the default database character set are not the same.
** Previously, somebody stored "illegal" characters using character set NONE in the client without using either introducer syntax or a CAST. In this case, transliteration fails when the data are read.
** On the "inward journey", introducer syntax or a CAST is not appropriate to the data to which it is applied.
** Possibly (though I haven't been able to reproduce it myself) characters that were "legal" for the character set were not present in the collation sequence used for storing the data (column or variable), i.e. there is no mapping for a certain character in the language that the COLLATE clause applies to.
For those who don't know about introducer syntax: you can force a literal string to be stored in a specific character set by prepending an "introducer". An introducer is the name of the character set, prefixed with an underscore. For example:
update atable
set acharactercol = _ISO8859_1 'ëúÖí'
A CAST would be like this:
update atable
set acharactercol = CAST ( 'ëúÖí' as varchar(nn) CHARACTER SET ISO8859_1);
You can't use the introducer syntax with replaceable parameters.
/heLen
>> Arithmic overflow of division by zero has occuredYep, it has to do with the way the exceptions are grouped. If it really is *that* error, you don't get the additional "transliteration" message.
>> arithmic exception, numeric overflow or string truncation
>>
>
>
>Personally, I've seen this error when I was trying to insert a string into a
>field that was not large enough to hold the data. I think I've seen it
>occur as a result of something else too. Seems like a bit of a generic
>error for related problems?
You get (first) the error message associated with the SQLCODE, followed by (if applicable) the message associated with the GDSCODE. The idea is that you can trap the high-level or the low-level exception, according to need. It's not a propos for this group of exceptions, since the transliteration error can't be solved by attacking any of the problems listed by the high-level message.
Transliteration errors happen under one or more of the following conditions:
** The connection character set and the default database character set are not the same.
** Previously, somebody stored "illegal" characters using character set NONE in the client without using either introducer syntax or a CAST. In this case, transliteration fails when the data are read.
** On the "inward journey", introducer syntax or a CAST is not appropriate to the data to which it is applied.
** Possibly (though I haven't been able to reproduce it myself) characters that were "legal" for the character set were not present in the collation sequence used for storing the data (column or variable), i.e. there is no mapping for a certain character in the language that the COLLATE clause applies to.
For those who don't know about introducer syntax: you can force a literal string to be stored in a specific character set by prepending an "introducer". An introducer is the name of the character set, prefixed with an underscore. For example:
update atable
set acharactercol = _ISO8859_1 'ëúÖí'
A CAST would be like this:
update atable
set acharactercol = CAST ( 'ëúÖí' as varchar(nn) CHARACTER SET ISO8859_1);
You can't use the introducer syntax with replaceable parameters.
/heLen