Re: [Firebird-devel] ERROR:Malformed string

[Alexander P. <pes...@ma...>]

On Monday 09 November 2009 19:01:15 Nikolay Samofatov wrote:
> Dmitry,
>
> Dmitry Yemanov wrote:
> > Nikolay Samofatov wrote:
> >> Dmitry, I believe this topic merits RM attention. Something needs to be
> >> done to remedy the situation both for Firebird 2.1 (corruption by
> >> default) and Firebird 2.5 (error by default).
> >
> > I don't think that *any* default processing can be good enough. The
> > engine doesn't know for sure what charset was used to store data or
> > metadata. We can look at the database charset and even suppose that
> > attachment charsets were the same, but anyway it's just a guess with
> > accuracy less than 100%. I strongly believe that guessing is not what
> > the engine should do.
>
> The fact that gbak allows restoring old backups without
> -fix_fss_metadata switch *already is* the guess that metadata was stored
> in UTF8.

This is your interpretation. In the world do exist databases that use plain 
ascii, and do not need intl support at all. We MAY restore such databases 
without -fix_fss_* switches and without guesses.

> This guess is wrong in the majority of cases.

Agreed, restore of old backups should be abandoned at once when we meet 
non-ascii character. With appropriate (unsupported character, please retry 
with a -fix_fss_* switch) message.

> > The metadata upgrade scripts in v2.1 are documented, the same is true
> > for the new restore switches in v2.5. We already had quite a few support
> > questions about the <subject> error and asked them to pay more attention
> > to the release notes. Nobody was blaming the server for being broken.
>
> I understand the release notes thing, but Firebird (unlike other
> databases) is supposed to work by default and be user-friendly.
> And FB 2.1/2.5 migration the process goes contrary to this logic.

Being user-friendly in this case can cause a lot of harm to users. When one 
gets wrong unreadable for him data in database, will it be user friendly?

> For every compaint like this you have a bunch of silent users who simply
> ditch the migration attempt.

Everyone is free to give up at first small error:-)) If nothing else helps, 
let them read relNotes.