Hi Claudio,

Just to let you know that I appreciate greatly the explanation and it
clears my mind. The database in question returning the problem was a
client's, but I also have a copy to work with. At least now, I know what
to look for and how to find the potential problem record, if it occurs
again and with another client. Even after changing the field size, it did
give me an error the next time running my restructuring program, but my
test case DB didn't give me any errors by following the same steps. So, I
told my client which record was the culprit and how to correct the
problem. They also had another field that had weird data and didn't seemed
entered by them, because of the other fields in the record didn't match,
but this couldn't have caused an error at the db level, because the field
value was in the type's range. Could it have been a mishap that the
culprit value got in the record because of an external factor? i.e. abrupt
shutdown while in transaction(just speculating here). I don't think it was
IB or FB's fault for what happened and I don't know what the circumstances
would be when it actually did happen.

Anyway the best remedy that I've found here was to make the modifications
in the field to eliminate the problem in the first place, now that I know
how to find it. Also, to answer one of your questions as to why unicode is
used, we're using it in preparation for countries where it would be needed,
since our market is not limited to Canada and the US and we started to have
some interested people from China.

Thanks again for your patience. And keep up the excellent work on Firebird.


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