Philip wrote:
On my dev server, I thought I'd try out 2.5.1rc1, without doing a full backup/restore from my current database, which has been running in 2.1.4 for a while. I ran across some issues with Flamerobin / IBPP Logic exception (I've reported it) and decided for the time being to rollback to 2.1.4. But in the mean time, I had made changes to triggers and stored procedures. In 2.1.4, I now get errors about unknown BLR code 190 -- of course it doesn't tell me exactly which SP or trigger is at fault, so I'm having to poke around a bit. (There's a request in the tracker for a "recompile" feature -- I could use it to make "recompile all" -- but that's not planned before FB3.)
Anyway, my question is this: when a newer version of firebird is touching an older version's files (by ODS version), is it expected to go ahead and use new BLR codes that will be incompatible when reverting? (Yes, I know, I didn't follow best practices, ...)
By the way, backup/restore is NOT a solution for this. The restore will fail with the same BLR error. So if you have a database like this, make sure you recompile all your procedures/triggers (via ALTER statements) first. (Thank you IBExpert. 2000 procedures and 5000 triggers take a while to recompile, but at least that worked, and I didn't have to try to figure out which one was at fault manually.)
Ann W. Harrison answers:
Yes, the engine does use new BLR features on an old databases, and if you use them, you've cut off your route backward, short of doing a metadata dump (isql -x), fixing the places that don't compile on the older version, and dumping your data back to the new database created with the old software.