Subject Re: 1.5.3 NONE -> 2.5 UNICODE_FSS
Author martin.agren
After abanoning gbak I went for a db script generated from flamerobin. It halted 100 times, mainly because of (constraint-) trigger and not NONE characters. After exclusion and editing it ran all the way w/o errors, but when commited the db was still empty of metadata (!).

I then tried 'commit after each table' and I got domains and procedures in, but coming to the tables it wouldnt go any further, I think dependencies kicked in.

--- In, Thomas Steinmaurer <ts@...> wrote:
> Martin,
> >>>>> -I dont need to bring along the data, metadata upgrade will do
> >>>>> -Metadata includes local characters (åäö in custom exceptions for example) in NONE charset db
> >>>>> -Big (huge?) database when it comes to # of triggers and procedures
> >>>>> -Tried backup/restore with -fix_ flags
> >>>>
> >>>> - What was the exact usage of gbak?
> >
> > Maybe I was unclear here - I used the -fix_fss_metadata flag with gbak, which at first glance seem to be what I need. But my conclusion was that gbak cannot used, since it doesnt have a target charset flag at restore. I end up with another NONE db.
> You are mixing things up here. The -fix_fss switches have to be used if
> you get a "malformed string" exception during restore, but this won't
> change the character set of your database.
> For changing the character set, you have to:
> - Extract the database DDL from the existing database
> - Create a new empty database with the new character set (e.g. UTF8)
> - Execute the DDL in the new empty database
> - Transfer data from your existing database into the new one
> --
> With regards,
> Thomas Steinmaurer
> Upscene Productions
> Download LogManager Series, FB TraceManager today!
> Continuous Database Monitoring Solutions supporting
> Firebird, InterBase, Advantage Database, MS SQL Server
> and NexusDB!