El jue, 06-10-2011 a las 14:10 +1300, Helen Borrie escribió: > > At 12:52 PM 6/10/2011, Maximiliano Robaina wrote: > >> > > >> >What could be the problem ? > >> > >> > http://www.firebirdsql.org/file/documentation/release_notes/html/rlsnotes251.html#rnfb25-utils-gbak-fix01 > >> > >> ./hb > > > >Hi Helen, > >Thanks for the tip, it works fine although the doc wasn't very clear > for > >me. Apparently, the problem was when trying to restore a stored > >procedure > >BTW, Why might this have happened? > > The source text of stored procs (and several other types of object, > such as CHECK constraints) is stored in a blob, as is the "compiled" > BLR code. When you restore a database, the BLR is not recreated: the > same BLR is used until next time you recreate or alter the object. > > Historically, the engine did not do the right thing regarding the > transliteration of strings embedded in the source and the BLR. In > v.2.1 and 2.5 a lot of work was done to address the international > language issues, as you probably know. A side effect of this was that > everything that was read from data and metadata became subject to > "well-formedness" checks. Hence, on restoring, those previously stored > source and BLR objects are throwing "malformed string" errors when > gbak tries to read and write the data in these system table records. > This very old bug affects user blobs, too, if they have been stored > using character set NONE and the client is configured to read a > specified character set to which the stored data could not be > transliterated. > > In v.2.1 there were scripts in ../misc that you could run to repair > the metadata blobs and also use as a template for repairing the > similar errors in blobs in your user data. The repair switches were > added to the gbak restore code in v.2.5 to do the same corrections to > metadata and data, respectively, during the process of restoring a > database for upgrade. > > ./heLen
Very clear explanation ! Thanks a lot. --- Maxi
