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