|
From: Adriano d. S. F. <adr...@gm...> - 2009-11-09 00:18:56
|
Nikolay Samofatov wrote: > Adriano, Dmitry, > > Adriano dos Santos Fernandes wrote: >> Nikolay Samofatov wrote: >> >>> Question: why the engine cannot behave in a smart way by default? >>> >>> Literally, if backup version is less than BCK_ods11_2 imply the use of >>> database character set (att_database_dfl_charset) with FIX_FSS_METADATA >>> option (isc_dpb_lc_ctype). This will cure 90% of cases: situations when >>> database character set is specified. >>> >>> >> And what you'll do with the 10% that used things *correct*, and has the metadata stored with UTF-8 and have a different database charset? >> > Remaining 10% use NONE as the database character set and not much can be > done to help them. ?? Sorry, you're mixing things and expecting a proposal that will not fill cases. Database charset has nothing to do with metadata, and correct/incorrect metadata does not depend on NONE/other database charset. > I believe it was not possible to use things "correctly" in a way you > describe with Firebird 2.0 and earlier. So for backups < BCK_ods11_1 > logic holds accurately. > > With Firebird 2.1 (BCK_ods11_1) the most common sight is the corrupt > database with half of procedures in WIN1251 (migrated from 2.0) and the > other half in UTF8 (created while in 2.1). > Luckily, WIN1251 is 8-bit character set, so any UTF8 procedures you > created while in Firebird 2.1 are converted without 'malformed string' > exception and you can than repair them manually after FIX_FSS_METADATA > is applied. > In any case, manual repair work is required. So maybe 'Malformed string' > is the good start for this particular scenario. > > 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). > > In the meantime, we brace ourselves for more repair work. > Repair work? Teaching people to pass a parameter for a switch? Adriano |