On 23/11/2016 06:15, Roman Simakov wrote: > 2016-11-23 2:26 GMT+03:00 Leyne, Sean <s...@broadviewsoftware.com>: >> 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. > Why not to use the same sync objects? :) Locks, ASTs, flags of > invalidated cache? > The table t does know about new record format. The view v also must know it. > > I suppose it's not so easy but I agree it must be. > See "Metadata locking policy and caching" in fb-architect archives.
Seems fb devs did prefer what works (laugh) currently than implement a reliable solution. However, it seems for me that Alexandre's problem is not what Sean talked. The problem him talked occurs even after disconnect and reconnect, no? Adriano ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
