Issue Details (XML | Word | Printable)

Key: CORE-789
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Adriano dos Santos Fernandes
Reporter: Pavel Cisar
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Collation backup of RDB$DEFAULT_COLLATE_

Created: 17/Sep/03 12:00 AM   Updated: 12/Nov/09 03:39 PM
Component/s: GBAK
Affects Version/s: None
Fix Version/s: 2.5 Alpha 1

Time Tracking:
Not Specified

SF_ID: 807996


 Description  « Hide
SFID: 807996#
Submitted By: pcisar

It would be very nice if
RDB$DEFAULT_COLLATE_NAME in table
RDB$CHARACTER_SETS works with backup and
restore.

When i change the default collate like :

update RDB$CHARACTER_SETS
  set RDB$DEFAULT_COLLATE_NAME = 'DU_NL'
where RDB$CHARACTER_SET_NAME = 'ISO8859_1'

Every new created (var)Char automaticly has the default
characterset / collate.

Currently when an Backup / Restore is done these
information is lost.

Regards,
Arno

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alice F. Bird added a comment - 14/Jun/06 09:42 AM
Date: 2005-07-24 21:44
Sender: asfernandes
Logged In: YES
user_id=940451

Dmitry,

The problem is not that DEFAULT_COLLATE_NAME is not
backed-up. It is.

The real problem is that all character sets and collations
initialized by the engine has RDB$SYSTEM_FLAG = 1.

I'd reported the same thing to Claudio two days ago about
COMMENT ON and RDB$DESCRIPTION.

Maybe we should treat RDB$CHARACTER_SETS and RDB$COLLATIONS
specially, backing-up system items and modifing records in
restore.

What do you think?

Alice F. Bird added a comment - 14/Jun/06 09:42 AM
Date: 2005-07-24 18:26
Sender: dimitr
Logged In: YES
user_id=61270

Adriano, do you agree? Could you please take care about this?

Poul Dige added a comment - 22/Apr/07 01:58 PM
I don't know if this is related, but when I try t

to backup a 2.0 database in 2.1
**********
gbak: writing domain RDB$287
gbak: writing domain RDB$288
gbak: writing domain RDB$289
gbak:writing shadow files
gbak:writing character sets
gbak:writing collations
gbak:writing tables
gbak: ERROR:Unable to complete network request to host "127.0.0.1".
gbak: ERROR: Error reading data from the connection.
gbak: ERROR: An existing connection was forcibly closed by the remote host.
gbak:Exiting before completion due to errors
**********


- restore the same backup created (witout problems) in 2.0 I get the following error:
**********
gbak: committing metadata
gbak: ERROR:unsuccessful metadata update
gbak: ERROR: TANSAETTELSE <- one of the tables in the db
gbak: ERROR: CHARACTER SET ISO8859_1 is not installed
gbak:Exiting before completion due to errors
**********
At some point I got a collation error, "ISO8859_1 not installed" during the restore process, but I can'r reproduce it right now...

Regards
Poul Dige
Tabulex

Poul Dige added a comment - 22/Apr/07 02:03 PM
Doh!

The 8859_1-bug that I mentioned above IS actually a part of the problem that GBAK reports during restore... so it is quite easy to reproduce :)

Poul

Poul Dige added a comment - 22/Apr/07 02:20 PM
Sorry!

Above seems to origin from uninstalling FB2.0 and installing FB2.1 still having a 2.0 process running (CS). after killing all FB-related processes in the taskmanager and restarting FB2.1 everything seems to work (at least for now :)

Regards
Poul