| Subject | Re: [firebird-support] Error on restore FB2.1 backup into FB2.5 |
|---|---|
| Author | Helen Borrie |
| Post date | 2011-10-06T01:10:19Z |
At 12:52 PM 6/10/2011, Maximiliano Robaina wrote:
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
>> >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.
>> >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?
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