At 21/03/2002 09:52 PM, you wrote:

> > Just to add to my last reply. I just tried Ann's suggestion, in my
> > application, to have additional steps to perform the wanted task and it
> > works great and doesn't give any errors. And, I can do the backup.
>
>So, is your case totally repeatable at will with an example table and a few
>rows? It seems like a good test case.

Hi Claudio,

Here's a twist to the case. When using unicode no problem occurs. When
using normal ASCII for the character set, I get the arithmetic overflow
error immediately. I just checked my database, where there was no error, I
got a surprise after performing the transformation from varchar(18) unicode
to varchar(6) unicode. The field is defined as "varchar(6) character set
unicode_fss" and the value in the field is "0101014876". In my book, this
shouldn't happen. Definitely, when I tried copying the value from this
field to a field varchar(6) character set ascii, the arithmetic overflow
error popped up.

Is there somewhere in Firebird's code that might be letting this go
by? And, why simply renaming the field name gives an error when doing the
backup, but if I copy to a new field, with the same definition, I don't get
the error. The odd thing is that with the test case that i created, I
never got an error, even by following my original steps.

I did perform a simple test to show this.

1. I created a new database.
2. I created a table with 1 field(field1) of type "varchar(18) character
set unicode_fss".
3. I inserted a few records, making sure that some of the values were over
6 characters long.
4. I then proceeded to created a temp_field of type "varchar(6) character
set unicode_fss".
5. Copy data from field1 to temp_field: update table1 set temp_field=field1
No errors occurred.
6. Execute: select * from table1
The resulting data in field1 and temp_field are the same.
7. Create a second temp_field2 of type "varchar(6) character set ascii"
8. Copy data from field1 to temp_field2: update table1 set temp_field2=field1
Arithmetic overflow error occurs.

Is there an explanation why it is happening this way? Is it as
designed? I know that unicode_fss has 3 bytes per character, but looking
at the results, it's almost as if it's the field length that is used for
comparison, instead of the field's character length.

Have a nice day.


Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.accramed.ca)