We are in the process of upgrading our app from using FB 2.0.1 to FB 2.5, and have a just a few users beta testing that.

I have a DB from a user of that beta version of our software, that has been opened successfully in our app using FB 2.5, and that seems to behave successfully in the app. It can be backed up successfully with gbak, but if we try to restore it with gbak, we get:

gbak: ERROR:Malformed string
gbak: ERROR:Invalid data detected. Use -FIX_FSS_DATA option.
gbak:Exiting before completion due to errors

I've Googled a lot about this and that -FIX_FSS_DATA option seems to only really be relevant when restoring DBs from much earlier versions of FB - but this is from the same version! Also, I tried adding that option to the gbak restore command line, and the result is the same failure.

I did get the impression it could be about data types, perhaps particularly in BLOB fields. So I narrowed it down to the BLOB fields in our DB, and it turned out that there was one value in in field (type BLOB SUB_TYPE TEXT) in one row of the DB, that if I cut the value out in our UI, saved the row, then pasted the same value back in again in our UI, and saved the row again, the problem goes away - a backup made after that can be restored!

I cannot see anything funny in the value - it's just some text, with a couple of embedded CR/LF pairs in it.

This is obviously extremely worrisome, because we are not aware of any previous user when we used FB 2.0.1 that ever could not restore a backup. It is not good if we are providing software where in some cases, backups users make cannot be restored! And we don't even know how to detect such a problem, since there didn't appear to be anything wrong with the text in that problem field.

Any thoughts or suggestions? Thanks.