Konwersja bazy na UTF-8

Może ktoś polecić jakieś darmowe środowisko do zarządzania bazami InterBase Firebird - potrzebuję przekonwertować starą bazę z WIN1250 na UTF-8.

Do Firebirda to tylko IBExpert moim zdaniem. Mają wersję personal, która ma ograniczenia i o ile dobrze pamiętam posiada wymóg aktywacji raz na miesiąc. Jednak powinieneś móc dokonać takiej konwersji bez większych problemów.

Nie zrobisz tego automatycznie. Musisz dodać nowe pola utf8 przepompować dane, dropbac pola win1250, założyć nowe utf8 i znów przepompować dane. Można napisać skrypt, który wygeneruje SQL na podstawie tabel systemowych. Sama zmiana typu na polu spowoduje niespójność binarnych danych względem metadanych. Nie ma jako takiego automatu.

somedev napisał(a):

Można napisać skrypt, który wygeneruje SQL na podstawie tabel systemowych. Sama zmiana typu na polu spowoduje niespójność binarnych danych względem metadanych. Nie ma jako takiego automatu.

Ale po co pisać skrypty, jak taki IBExpert zrobi Ci to za pomocą 3 klików? Dodatkowo jak ktoś mądrze robił bazę danych (używa domen zamiast wszędzie definiować pola w każdej tabeli), to wystarczy w wyeksportowanym pliku DDL pozmieniać kodowanie z WIN1250 na UTF8 dla wszystkich domen i już. Potem utworzyć nową bazę, wykonać skrypt i powinno być ok.

A co z danymi? Gdzie ibe to sam zmieni? Jak zmienisz kodowanie domeny to gback się zrobi ale nie przywróci się już. Jak jest inna rozpiętość binarna danych niż domena przewiduje.

amprogramming napisał(a):

Może ktoś polecić jakieś darmowe środowisko do zarządzania bazami InterBase Firebird - potrzebuję przekonwertować starą bazę z WIN1250 na UTF-8.

.... to może w drugą stronę ... jak zmienić w Lazarusie 2.0 kodowanie na WIN1250 ?

somedev napisał(a):

A co z danymi? Gdzie ibe to sam zmieni? Jak zmienisz kodowanie domeny to gback się zrobi ale nie przywróci się już. Jak jest inna rozpiętość binarna danych niż domena przewiduje.

A Ty przeczytałeś co ja napisałem? Pisałem o eksportowaniu wszystkiego do DDL i co za tym idzie wszystkich danych jako czysty SQL. Gdzie tu jest miejsce na gbak? W ten sposób można zmieniać np. wersję bazy w dół. Czego gbakiem nie zrobisz. Tak samo należy postąpić w przypadku konwersji kodowania na UTF8. Robimy to tak:

1. eksport metadanych wszystkich tabel, procedur, wyzwalaczy (DDL) do SQL'a
2. zmiana WIN1250 -> UTF8 w pliku *sql,
3. eksport danych do postaci insert into...
4. utworzenie nowej bazy
5. wykonanie skryptu DDL
6. wykonanie skryptu dodające dane do bazy.

DDL nie ma nic do danych. Niemniej to co napisałeś ma sens. Jednak to co innego niż wcześniej napisałeś. Ten sposób to w przypadku rekonstrukcji bazy, ja pisałem, o sposobie na migracje tych danych na żywo, bez konieczności zabijania bazy (pracuje z takimi systemami), nie niszczę innych kolumn nie varchar (czyli nie musisz liczyć indeksów co trwa czasem kilka dni ). Gbacki robi się cyklicznie żeby 1 - backup, 2 - sprawdzanie integralnisvi danych oraz czy baza nie jest uszkodzona.

@somedev ok, niewyraźnie się w pierwszym poście wyraziłem. Mea cupla.

To, że DDL nie ma nic do danych to jasne. W taki sposób jak opisałem zdarzało mi się wielokrotnie zmieniać wersję bazy z FB2.5 na FB2.1 i wszystko było w porządku. Wiadomo, że wtedy trzeba brać pewne rzeczy pod uwagę. Chociażby to, czy w ogóle odpalą się niektóre zapytania. Jednak jeśli się nie używa specyficznych dla FB 2.5 rzeczy to zadziałać powinno bezboleśnie.

Co do Twojej metody jest fajna, jednak operacje na żywo trochę mnie niepokoją... Tak wiem, czasami nie da się inaczej. Jednak zawsze budzi to we mnie niepokój.

Też podzielam Twój niepokój, jednak czasami inaczej się nie są. Zawsze można robic to etapami pomiędzy którymi lokujemy bazę nbackup z plikiem delty - jak się uda konwersja tabeli to mergujemy, jak nie to odlokowujemy usuwając plik delty.