At 02:28 p.m. 17/01/2013, fabianchocron wrote:

>> OLD/NEW pseudo-records have the same format as regular table
>> records, inheriting the same length limits. And this is not a bug.
>
>Hi Dmitry
>
>mmm, it does not make sanse to me, think it this way:
>
>The field on table is say char 32
>The insert is trying to insert a string of 40 characters, say "AAA..." repeated 40 times
>What you are saying is the old and new records are char (32), and that is fine, as the trigger is assigning a string of say 31 characters into a char 32. Why is it failing?

It is failing for the reason explained by Dmitry and Ann: the NEW variable has the same size as the column definition - in your example, char(32). Therefore, there is no way to store a string of 40 characters in the NEW variable. The exception occurs *before* the context variables are created, do you see?

>the instruction on the trigger is:
>
>new.mychar = substring(new.mychar from 1 for 31)
>
>I don't see where the code is breaching the rules?

OK, one more time. NEW.MYCHAR is defined by the size of the column named MYCHAR in your table. Your substring expression cannot work because the exception happens in the parsing of the dynamic value passed in the INSERT statement.

>Unless Firebird is comparing the size of the original string posted in the insert instruction against the database, and that to me sounds like a bug.

You think it is a bug if a database engine protects databases from string overflow? Oh dear, dear, you need to take some deep breaths, methinks.

Triggers work in database operations, not in the client.

./heLen