2013-10-10 12 views
5

Ja próbuje połączyć się z bazy danych Firebird uruchomiony w oknach od klienta linux, a gdy próbuje attache bazy danych pojawia się następujący błąd:Firebird CHARACTER SET UTF8 nie jest zdefiniowana

bad parameters on attach or create database, CHARACTER SET UTF8 is not defined 

Mam google i przeszukał odpowiedzi tutaj, ale nie może znaleźć rozwiązania.

Jakieś sugestie na temat tego, jak można to rozwiązać po stronie klienta, czy też wymaga on odbudowania bazy danych przy pomocy UTF8?

stronie klienta używam węzła js z modułem węzłów Firebird, wersja silnika po stronie serwera jest 2,5, ODS wersja jest 11,2

function dbConnect(cb){ 
    fb.attach({ 
     host: '192.168.42.233', 
     database: 'gi', 
     user: 'SYSDBA', 
     password: 'xxxxx' 
    }, function(err, db){ 
     if (err) console.log(err.message); 
     else cb(db); 

    }) 
} 
+0

Jakiego dysku używasz do łączenia się z serwerem? –

+0

Witam, po stronie klienta używam nodejs z modułem node-firebird. – crankshaft

+1

Proszę podać kod, którego używasz do połączenia, wersję bazy danych ODS i wersję Firebird. –

Odpowiedz

2

komentarz Harriv skłoniło mnie aby przetestować swój pomysł, że to może być spowodowane przez brakujący wpis w RDB$CHARACTER_SETS. Gdybym ręcznie usunąć UTF8 z tej tabeli systemowej uzyskać ten sam błąd, gdy próbuję się połączyć z UTF8:

SQL Message : -924 
Connection error 

Engine Code : 335544325 
Engine Message : 
bad parameters on attach or create database 
CHARACTER SET UTF8 is not defined 

Rozwiązaniem jest tworzenie kopii zapasowych bazy danych i przywrócić go ponownie. To spowoduje odtworzenie tabeli systemowej RDB$CHARACTER_SETS, aby ponownie dodać UTF8.

Pamiętaj, że rozwiąże to problem tylko w przypadku braku numeru UTF8 z RDB$CHARACTER_SETS. Jeśli tak, powinieneś zadać sobie pytanie, dlaczego w ogóle go brakowało. Może DBA lub inny programista usunął wpisy z RDB$CHARACTER_SETS, jeśli tak, to prawdopodobnie dobrze jest dowiedzieć się, dlaczego tak się stało.

Na przykład: być może baza danych używa NONE jako domyślnego zestawu znaków (i dla każdej kolumny), a to było sposobem na zapewnienie, że ludzie łączą się tylko z "właściwym" zestawem znaków przez usunięcie wszystkich innych opcji (normalna baza danych Firebird 2.5 zawiera 52 wpisy w RDB$CHARACTER_SETS). W takim przypadku upewnij się, że rozwiązałeś ten problem przed połączeniem z UTF8, w przeciwnym razie prawdopodobnie doświadczysz jakiejś formy uszkodzenia danych (podczas odczytu lub zapisu) w wyniku nieprawidłowej transliteracji.

Rozwiązaniem tego problemu jest utworzenie nowej bazy danych z odpowiednim domyślnym zestawem znaków (oraz dla kolumn) i przepompowanie danych ze starego do nowego (upewniając się, że odczyt i zapis są wykonywane przy użyciu odpowiedniego znaku zestaw). Po tym Firebird może zająć się transliteracją między zestawem znaków bazy danych (lub kolumny) i zestawem znaków połączenia (z wyjątkiem aplikacji łączących się przy użyciu NONE jako zestawu znaków połączenia).

Powiązane problemy