> SQL> > SQL> select * from v; > > A > ====== > Statement failed, SQLSTATE = 22001 > arithmetic exception, numeric overflow, or string truncation -string right > truncation > SQL> > > > As you can see.. there is no error until the records are inserted or updated > with a value that the length is greater than the previous size... In a way or > another, the view stores the datatype (record format ?), and if a string is > greater than that, the error is trown.. IIRC the same occurs with computed > columns (did not made a test case to check it out) > > To make the things worse... The error is the one I consider most cryptic, > since > you don't know the column name, the value and wich record is the culprit.. a > very annoying one to get on production... > > The same error can be reproduced on FB 3.0. > > What do you think about it ?
Think this is a perfect example of why DDL changes should only be performed in single-user/connection mode. I can't imagine how the engine could manage to keep the schema/object cache and transaction context in sync or, in the absence of that, to 'broadcast' that schema has changed and any existing cached object should be released as soon as possible, to force the object definition to be reloaded. Sean ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
