Adriano, > CORE-3073 [1] requires special BLR verb meaning "get the default value of a > field". There is request to expose the same functionality in SQL too, but > doesn't matter here. > > These cascade triggers are system triggers but are backed-up and restored. If > we use new BLR on them, downgrades via gbak will not work. > > So is this acceptable, that in some cases people must recreate database from > script to downgrade?
In some respect that is simply a fact of life, to go forward sometimes you don't get the chance to take a step back. Having said that, I was wondering if there could be a system procedure which we could add to all existing versions which would force the engine to re-process the source of the schema object to recreate the BLR based on the rules of the current engine version. In the case noted, that would mean that the existing bug/limitation would still apply but the new BLR would be removed from the objects. Further, we could add a new GBAK switch to have this re-compile procedure run at the end of the restore. Sean I've never tried this but what would happen if I executed: UPDATE RDB$Procedures SET RDB$ProcedureSource = RDB$ProcedureSource || '--'; Would this force the engine to recompile the BLR? ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
