> On Nov 22, 2016, at 7:26 PM, Leyne, Sean <s...@broadviewsoftware.com> wrote: > > >> 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.
Exactly that mechanism does exist. Every connection holds an existence lock on objects it has cached. The lock includes a mechanism to notify the holder if an object has changed. Since IB V1. Cheers, Ann ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
