Migracja Firebird 2.5 do 4.0 dla biur rachunkowych

Uwaga
Instrukcja przeznaczona dla użytkowników zaawansowanych i lokalnych administratorów.

Nowa wersja Firebird 4.0 wprowadziła wiele usprawnień do systemu zarządzania relacyjnymi bazami danych. Udoskonalono wykorzystanie sprzętu wieloplatformowego i dużych przestrzeni adresowych, co przekłada się na wzrost wydajności.

Poprawiono także bezpieczeństwo poprzez wydłużenie haseł i domyślne szyfrowanie transmisji. Obsługa międzynarodowych stref czasowych, operacje wsadowe w API, wbudowane funkcje kryptograficzne, nowy ODS (wersja 13) z nowym systemem i tabelami monitorowania, maksymalny rozmiar strony zwiększony do 32 KB itd.

Aby RAKSSQL był zgodny z nową wersją Firebird 4.0 należy wymienić serwer bazodanowy.

W związku z tym niezbędna będzie też aktualizacja wszystkich istniejących baz danych.

W celu dokonania migracji systemu bazodanowego z Firebird 2.5 na Firebird 4.0 można użyć co najmniej trzech metod. Pierwsza to instalator pakietu RAKSSQL ze specjalnym parametrem uruchamiającym proces migracji. Druga – dodatkowy migrator a trzecia metoda to mechanizm dearchiwizacji w module Administrator. Metoda trzecia będzie również opisana z użyciem konsoli Windows.

Wszystkie metody pozwolą na osiągnięcie efektu końcowego czyli wymiany systemu bazodanowego i modyfikacji struktury baz danych .

Wycofanie się ponownie na obsługę Firebird 2.5 jest możliwe gdyż nie jest usuwany pierwotny katalog z bazami (bez cyfry 4 a końcu nazwy) a także nie są czyszczone kopie zapasowe wykonywane w czasie procesu migracji. W przypadku chęci powrotu na poprzedni Firebird należy zainstalować go z oddzielnego instalatora, gdyż nowe wersje instalatora RAKSSQL posiadają tylko instalację Firebird 4.0 .

Dodatkowo może być niezbędne poprawienie pliku Config.xml i wskazanie w nim starej ścieżki do baz danych. Jeżeli doszło do pełnej migracji wraz z zainstalowaniem nowej wersji RAKSSQL to do wycofania się z przejścia na nowy Firebird może być jeszcze potrzebna podmiana plików klienta w katalogu RAKSSQL/Bin. Pliki bibliotek obsługujących prawidłowo bez komunikatów starą wersję Firebird znajdują się w katalogu Migracja w miejscu instalacji Raks (Raks/Migracja).

W przypadku biur rachunkowych należy wziąć pod uwagę podczas przygotowań do migracji kilka czynników, które mogą się pojawić. Głównym z nich jest czas. Czas niezbędny na wykonanie kopii baz danych, odtworzenie ich oraz prawdopodobnie na koniec aktualizacja. A im więcej baz danych tym więcej czasu będziemy potrzebowali. W warunkach testowych mała baza kopiowała się ok 1,5 minuty. Odtworzenie trwało podobnie. Ale wynik może być niemiarodajny, ponieważ jeszcze w rachubę wchodzi szybkość sprzętu, na którym będziemy wykonywać operacje. Dlatego na potrzeby migracji biur rachunkowych od wersji 1265, jest wprowadzony mechanizm, który określa czas potrzebny na zrobienie backupu i odtworzenie a także bada kondycję baz danych. Raport przedmigracyjny dostępny jest również spod parametru, który uruchamia tę funkcjonalność.

Musimy też przygotować odpowiednią ilość wolnego miejsca na dysku. Możemy przyjąć trzykrotność wielkości katalogu DATA z bazami, które będą konwertowane plus zapas na kopię katalogu Raks z binariami.

Migracji nie należy wykonywać na raty. Cały proces należy przeprowadzić jednorazowo ze względu na powiązania między bazami firmowymi a bazą globalną, która jest nieodłączną częścią systemu bazodanowego RAKSSQL.

Uszkodzone bazy danych, jeżeli występują wśród użytkowanych firm powinny zostać naprawione przed migracją, gdyż zostaną inaczej pominięte w procesie konwersji. Jest to prawidłowe działanie, aby nie blokować migracji pozostałych firm. Naprawę można też wykonać w dowolnym momencie później i odtworzyć naprawioną firmę z backupu.

Metoda 1 – migracja za pomocą Instalatora.

Narzędzie wbudowane w instalator pozawala na najprostszą i najszybszą migrację prawie bezobsługową, ponieważ część czynności wykonuje za użytkownika pakiet instalacyjny, co skraca do minimum formalności związane z migracją silnika bazodanowego.

Metoda 2 – przejście na nowy Firebird z użyciem migratora.

Migrator jest tym samym narzędziem, które zostało zaimplementowane w instalatorze. Jednakże samodzielne uruchomienie narzędzia (z pominięciem instalatora) pozwala na swobodniejszy wybór wykonywanych czynności, ale okupione to jest trudniejszą obsługą. Metoda zalecana raczej dla zaawansowanych użytkowników komputerów lub lokalnych administratorów.

Metoda 3 – dearchiwizacja

Jest to chyba najstabilniejsza metoda. Jednak wymaga większej uważności w wyborze baz do odtworzenia i może zająć to większą ilość czasu związanego ze wskazywaniem backupów.

W sekcji „metody migracji” będą poszczególne metody szczegółowo opisane.

Wybór metody będzie chyba indywidualnie dobierany w zależności od czynników i subiektywnych preferencji osoby prowadzącej migrację.

Natomiast mogą zdarzyć się sytuacje problematyczne, wtedy podejście będzie indywidualne do każdej sytuacji. Typowe błędy zostały opisane na końcu instrukcji (załącznik 3) .

W skrajnych przypadkach po odinstalowaniu nowego Firebird 4.0 może pozostać nieużywana usługa. Jak usunąć usługę w systemie Windows 10, 8, 7 opisano pod koniec instrukcji (załącznik 1)

Instrukcja instalacji kilku instancji Firebird na jednym serwerze jest dostępna m.in. pod adresem https://www.youtube.com/watch?v=rYD0hEQOfz0

W celu dokonania migracji serwera z Firebird 2.5 na Firebird 4.0 należy użyć instalatora z dodatkowym parametrem uruchamiającym proces migracji. W celu uzyskania parametru oraz instrukcji opisującej proces wprowadzenia prosimy o przesłanie formularza zgłoszeniowego dostępnego poniżej.

Chcę wykonać migrację samodzielnie

Metoda 1 – Proces migracji za pomocą instalatora

Aby rozpocząć proces migracji należy uruchomić proces za pomocą ściągniętego ze strony raks.pl instalatora.
https://raks.pl/aktualne-wersje/

UWAGA!
Migrację z użyciem instalatora należy wykonać tylko w momencie pracy na wersji o numerze niższym niż wersja najnowsza na dzień operacji, np. aktualna wersja na stronie RAKS to nr …1287 – Klient w momencie migracji musi pracować na wersji o niższym numerze ..1286, 1279.

Instalator RAKS uruchomiony z parametrem migracyjnym przy zainstalowanej już u Klienta wersji o tym samym numerze będzie próbował odinstalować program.

Na ten moment, aby uruchomić instalator, który przeprowadzi użytkownika przez proces migracji należy otrzymać odpowiedni parametr wraz z instrukcją od Działu Wsparcia Użytkownika.

Po zastosowaniu się do instrukcji DODATEK DO INSTRUKCJI MIGRACJI BAZ DANYCH i FIREBIRD 2.5 NA WERSJĘ 4.0 W BR należy postępować zgodnie z poniższymi wskazówkami.

W pierwszym oknie instalacyjnym pojawi się pytanie o chęć dokonania aktualizacji i zgodę na dokonanie deinstalacji w pierwszym etapie.

W kolejnym oknie należy potwierdzić lub zaprzeczyć na pytanie o chęć rozpoczęcia procesu migracji na nowszą wersję Firebird.

W przypadku odpowiedzi przeczącej na pytanie z poprzedniego okna pojawi się taki komunikat I proces instalacji zostanie przerwany.

Jeżeli wcześniej została potwierdzona chęć migracji to w kolejnym oknie będzie sugestia, którą z wersji Firebird chcemy zainstalować.

A następnie pytanie o katalog instalacji

W kolejnym oknie będzie widoczny proces instalacji binariów programu Raks.

W następnym kroku będzie widoczne okno migratora z parametrami migracji.

W oknie tym będzie też widoczna ścieżka do katalogu, w którym zostaną wykonane backupy baz danych podlegające konwersji. W jednym z następnych kroków zostaną odtworzone do folderu xxx4.

Domyślnie jest to katalog temp użytkownika w Windows.

Dodatkowo jest utworzony podkatalog (z nr guid w nazwie) rozdzielny dla każdej konfiguracji.

Dla celów bezpieczeństwa, aby mieć dostęp do dodatkowego backupu katalog ten nie jest czyszczony w procesie migracji, dlatego należy go samodzielnie wykasować, jeżeli jest taka potrzeba. Zostanie też samodzielnie wyczyszczony przez Windows w sytuacji przepełnienia dysku.

W oknie tym zostaną odczytane wszystkie zapisy konfiguracji programu, odczytane z configu położenie katalogu z bazami danych oraz sugestia, w jakim katalogu zostaną zapisane bazy danych po konwersji.

Aby zachować pierwotne bazy danych sprzed konwersji nowe bazy przemigrowane będą przechowywane w nowym katalogu.

Domyślnie będzie to katalog w tym samym miejscu, co katalog pierwotny, nazwa będzie również prawie identyczna, z tą różnicą, że na końcu nazwy katalogu pojawi się cyfra 4. Można też wskazać własną ścieżkę.

Przykład:

Pierwotna nazwa katalogu Data, nowa nazwa będzie brzmiała Data4 a lokalizacja nie zmieni się.

Przejście do dalszego etapu należy potwierdzić przyciskiem „kopiuj bazy”.

Następne okno będzie pokazywać postęp kopiowania baz.

Widoczne będą informacje, którą z konfiguracji obecnie kopiuje i którą bazę.

Po prawidłowym (zakończonym sukcesem) przekopiowaniu baz danych nastąpi proces wymiany Firebird z wersji 2.5 na 4.0

Faktycznie kolejność czynności dokonywanych w tle będzie wyglądała następująco:

Wyłączenie usługi Firebird 2.5
Zmiana numeru portu, na którym pracuje Firebird 2.5 z 3050 na 3051
Instalacja Firebird 4.0
Oznaczenie jego instancji, jako domyślnej, przydzielenie portu komunikacyjnego TCP na 3050.

Po zainstalowaniu Firebird 4.0 i przejęciu kontroli nastąpi najważniejszy proces, czyli odtworzenie danych z wykonanej kopii wraz z konwersją baz.

Domyślnie kopie zostaną pobrane w wcześniej wskazanego miejsca a odtworzenie do katalogu, który także był wcześniej wskazany. W tym oknie nie da się już zmienić ścieżek i edycja będzie zablokowana.

Natomiast gdyby była tak potrzeba to te informacje są zapisane w pliku konfiguracyjnym, który można edytować. Plik znajduje się w katalogu instalacyjnym Raks, podkatalog Migrator, plik o nazwie FB25_FB40.settings .

Nie jest to wskazane aby go edytować a tym bardziej nie jest zalecane modyfikowanie zawartości pliku z ustawieniami. Informację ta jest podawana tylko na potrzeby skrajnych sytuacji.

Poniżej okna procesu odtwarzania danych z kopii wykonanej w poprzednich etapach:

Okno odtwarzania

Okno procesu, na którym widać postęp i kolejność odtwarzanych baz.

Po zakończonym procesie odtwarzania baz danych w tle zostaną dokonane następujące czynności:

Odinstalowanie Firebird 2.5
Podmiana binariów RaksSQL na nowszą wersję
Podmianę zapisów, co do ścieżki baz danych w Config.xml (na katalog z ‘4’ na końcu nazwy)
Zakończenie procesu migracji oraz aktualizacji programu.

Po powyższych czynnościach otrzymujemy program RaksSQL w najnowszej wersji, zainstalowany Firebird 4.0, bazy danych zmigrowane, config przepisany na nową ścieżkę.

Natomiast bazy danych są jeszcze w starej, niezaktualizowanej wersji, jaka była przed migracją.

I jak w każdej aktualizacji po zakończonym procesie podmiany programu, należy wejść do modułu Administrator, do sekcji Uaktualnienie a następnie zaznaczyć wszystkie bazy danych i nacisnąć przycisk Aktualizuj.

Metoda 2 – przejście na nowy Firebird z użyciem migratora

W następnym kroku będzie widoczne okno migratora z parametrami migracji.

W oknie tym będzie też widoczna ścieżka do katalogu, w którym zostaną wykonane backupy baz danych podlegające konwersji. Domyślnie jest to katalog temp użytkownika w Windows.

Dodatkowo jest utworzony podkatalog (z nr guid w nazwie) rozdzielny dla każdej konfiguracji.

W oknie migratora zostaną odczytane wszystkie zapisy konfiguracji programu, odczytane z configu położenie katalogu z bazami danych oraz sugestia, w jakim katalogu zostaną zapisane bazy danych po konwersji.

Aby zachować pierwotne bazy danych sprzed konwersji nowe bazy przemigrowane będą przechowywane w nowym katalogu.

Przykład:

Pierwotna nazwa katalogu Data, nowa nazwa będzie brzmiała Data4 a lokalizacja nie zmieni się.

Przejście do dalszego etapu należy potwierdzić przyciskiem „kopiuj bazy”

W jednym z następnych kroków bazy zostaną odtworzone do folderu xxx4.

Katalog ten w przypadku metody drugiej musi być samodzielnie założony. Jeżeli jest to na serwerze to należy też nadać odpowiednie uprawnienia do zapisu i odczytu w tym katalogu.

Przejście do dalszego etapu należy potwierdzić przyciskiem „kopiuj bazy”.

Okno postępu kopiowania:

Na koniec procesu kopiowania pojawi się komunikat o wykonaniu zadania.

UWAGA!
Po tym zadaniu nie kończymy działania migratora! Pozostawiamy go włączonego a jedynie możemy zrzucić do zasobnika systemowego, aby wykonać kolejne czynności!

Przerwanie na tym etapie wiązało by się z uruchomieniem migracji od początku.

Można też wymusić w późniejszym etapie uruchomienie migratora na sam etap odtwarzania, ale wymaga to przygotowania parametru, z którym uruchamiamy migrator.

Składnia parametru brzmi następująco: Etap=Odtwarzanie TylkoJednaOperacja=1

Umieszczamy parametr utworzonym w skrócie do migratora, lub w narzędziu za pomocą którego uruchamiamy plik wykonywalny migratora (np. TotalCommander)

Po wykonaniu kopii zapasowej a przed odtworzeniem danych należy wykonać jeszcze kilka niezależnych kroków.

Pierwszym z nich będzie wyłączenie usługi Firebird w Windows.

Drugim krokiem będzie odinstalowanie poprzedniej wersji Firebird. Deinstalację robimy zazwyczaj z okna Programów i funkcji Panelu Sterowania:

Potwierdzamy chęć deinstalacji.

I jeżeli pojawi się poniższy komunikat to oznacza, że pominęliśmy pierwszy i zapomnieliśmy wyłączyć działającą jeszcze usługę Firebird.

Trzecim krokiem będzie instalacja nowego Firebirda w wersji 4.0.2

Instalator do ściągnięcia ze strony lub dostępny w pakiecie z RAKSSQL.

https://firebirdsql.org/en/server-packages/

Uruchamiamy instalator z pliku EXE lub MSI:

Potwierdzamy miejsce instalacji.

Zaznaczamy elementy do zainstalowania:

Kolejne pytanie i naciskamy Dalej.

A następnie wybieramy rodzaj instalacji i dodatkowe parametry.

Jest to bardzo ważne okno i należy zaznaczyć elementy jak niżej:

Okno instalacji:

Okna końcowe:

W oknie końcowy proponuję nie zaznaczać uruchomienia usługi Firebird, gdyż należy nanieść jeszcze dodatkowe zmiany w plikach konfiguracyjnych.

Jeżeli jednak uruchomiliśmy Firebirda to usługę możemy zamknąć w menadżerze zadań.

Następnie przechodzimy do miejsca instalacji Firebird, do katalogu głównego:

I edytujemy w notatniku 2 pliku konfiguracyjne Firebird

Z powodu używania IBX i architektury, w jakiej działa RaksSQL, w firebird.conf należy ustawić klucze:

AuthServer = Srp256

ReadConsistency = 0

DataTypeCompatibility = 2.5

WireCrypt = Enabled

DefaultTimeZone = Europe/Warsaw

ServerMode = SuperClassic

Poniżej okna z modyfikowanymi parametrami

Przy każdej zmianie musimy zdjąć znak # aby zmiana zaczęła obowiązywać!

Następnie w pliku databases.conf zmieniamy wpis dla security.db:

security.db = $(dir_secDb)/security4.fdb

{

RemoteAccess = true

DataTypeCompatibility = 3.0

DefaultDbCachePages = 256

}

Po powyższych zmianach uruchamiamy Usługę Firebird:

W kolejnym kroku zakładamy katalogi do których będą odtwarzane backupy i nadajemy im stosowne uprawnienia.

Po zainstalowaniu Firebird 4.0 i przejęciu kontroli nastąpi najważniejszy proces, czyli odtworzenie danych z wykonanej kopii wraz z konwersją baz.

Domyślnie kopie zostaną pobrane z wcześniej wskazanego miejsca a odtworzenie do katalogu, który także był wcześniej wskazany. W tym oknie nie da się już zmienić ścieżek i edycja będzie zablokowana.

Nie jest wskazane aby go edytować, a tym bardziej nie jest zalecane modyfikowanie zawartości pliku z ustawieniami. Informacja ta jest podawana tylko na potrzeby skrajnych sytuacji.

Poniżej okna procesu odtwarzania danych z kopii wykonanej w poprzednich etapach:

Potwierdzamy spełnienie wszystkich wymagań.

I bazy zaczynają się odtwarzać i jednocześnie konwertować do struktury Firebird 4.0.

Jeżeli wszystko się uda migrator zostanie zamknięty bez generowania komunikatu końcowego.

Jeżeli pojawi się błąd szczegóły będą zazwyczaj dostępne w logu:

Po powyższych czynnościach otrzymujemy program RaksSQL w najnowszej wersji, zainstalowany Firebird 4.0, bazy danych zmigrowane, config przepisany na nową ścieżkę.

Natomiast bazy danych są jeszcze w starej, niezaktualizowanej wersji, jaka była przed migracją. Dlatego opcjonalnie na koniec dokonujemy standardowej aktualizacji z poziomu modułu Administrator RaksSQL.

Metoda 3 – z wykorzystaniem archiwizacji i odtworzenia baz danych

Migracja wszystkich baz danych następuje w trzech etapach, które polegają na:

1) wykonaniu kopii zapasowej wszystkich baz danych (*.fdb) (backup) na obecnie użytkowanej wersji Firebird 2.5,

2) odinstalowaniu Firebird 2.5 oraz instalacji Firebird 4.0,

3) przywróceniu danych z kopii zapasowej (restore) w wersji serwera Firebird 4.0.

Odpowiednia kolejność czynności związanych z migracją zapewnia optymalizację całej migracji.

Czynności wykonania kopii zapasowych możemy wykonać za pomocą modułu Administrator w RAKSSQL lub konsolowo z wykorzystaniem gbak.exe znajdującego się w katalogu BIN instalacji Firebirda.

Omówimy obydwa sposoby. Natomiast odtwarzanie wykonujemy tylko przy użyciu komendy Odtwórz kopie zapasowe w module Administrator, gdyż sam Raks ma wbudowane procesy, które konwertują odwołania do UDF’ów.

Archiwizacja i dearchiwizacja w module Administrator RAKSSQL:

Uruchamiamy moduł Administrator, przechodzimy na zakładkę Obsługa Baz Danych> Kopia zapasowa, zaznaczamy wszystkie bazy danych, które będą migrowane, naciskamy przycisk Twórz kopie zapasowe w celu uruchomienia procesu.

Wcześniej pod przyciskiem Ustawienia można wskazać miejsce wykonywania kopii zapasowej.

Po wykonaniu kopii zapasowej (backupu) dokonujemy poniższe czynności:

odinstalowanie Firebird 2.5
odinstalowanie dotychczasowej wersji RaksSQL
założenie nowego katalogu na bazy po migracji np. Data4 lub zmiana dotychczasowego na Data2.5 i założenie nowego o nazwie Data ( jeżeli posiadamy dodatkowe narzędzia lub moduły, gdzie wskazywana jest ścieżka położenia baz FDB zalecamy sposób drugi czyli zmianę dotychczasowego katalogu na Data2.5 i założenie nowego o nazwie Data)
zmiana w pliku konfiguracyjnym config.xml jeżeli zdecydowaliśmy się nowy katalog baz po migracji np. Data4.
zainstalowanie najnowszej wersji RaksSQL wraz z silnikiem baz danych Firebird4.0 (jeżeli instalator nie wykryje wersji FB2.5 zainstaluje wersję FB4.0)

Po wykonaniu wymiany i konfiguracji Firebird można dopiero przystąpić do odtworzenia danych z kopii zapasowej (backupu).

A następnie przystąpić do procesu aktualizacji baz danych.

Archiwizacja za pomocą GBAK.EXE:

Wykonanie kopii zapasowej odbywa się przy pomocy programu gbak.exe znajdującego się w katalogu instalacyjnym Firebird. Gbak jest programem konsolowym, dlatego wszystkie operacje będą wykonywane w interpreterze poleceń systemu Windows – cmd.exe. Najwygodniej jest początkowo ustawić się w konsoli na katalogu instalacyjnym Firebirda (przykład: cd C:\Programy\Firebird).

Wszystkie przedstawiane polecenia wykonywane są z logowaniem jako użytkownik specjalny SYSDBA z hasłem domyślnym masterkey. Jeśli hasło na serwerze jest inne, należy odpowiednio zmodyfikować poniższe komendy.

Backup przenoszonych bazy danych fdb należy wykonać komendą:

gbak -v –b -t -user sysdba -pas masterkey {host/path}{nazwa_pliku}.fdb {host/path}{nazwa_pliku}.fbk

Katalog, do którego wykonujemy backup, musi istnieć.

Po wykonaniu kopii zapasowej (backupu) dokonujemy czynności jak przy procesie wykonywania kopii z programu RAKS.

Powyższe czynności były już opisane w innej sekcji tej instrukcji. Postępujemy więc zgodnie z informacjami tam zawartymi.

Po wykonaniu wymiany i konfiguracji Firebird można dopiero przystąpić do odtworzenia danych z kopii zapasowej (backupu), korzystając z mechanizmu wbudowanego w program RAKSSQL (Administrator – kopia zapasowa – Odtwarzanie baz danych z kopii zapasowych.

Backup baz na Firebird 2.5 komenda:

gbak –v –b -t -user <username> -password <password> {host/path}<database> {host/path}<backup_file> –y <log_file>

Przykład:

gbak -v -b -t -user SYSDBA -password “masterkey” “C:\Programy\Raks\Data\F00001.FDB” “C:\Programy\Raks\Data\Backup\F00001__arch_%date%_%time:~0,2%-%time:~3,2%.FBK” -y “C:\Programy\Raks\Data\Backup\F00001_logs_%date%_%time:~0,2%-%time:~3,2%.txt”

oznaczenie {host/path} jest ścieżką dojścia do plików, jeśli pliki znajdują się w bieżącym katalogu – przedrostek jest niepotrzebny

Aby zatrzymać serwer, można skorzystać

z polecenia:

instsvc stop

Ponowne uruchomienie serwera umożliwia polecenie:

instsvc start

Czynności migracji czy uaktualnienia baz danych wykonujemy tylko na jednej maszynie (stanowisku) – na serwerze czy głównym komputerze, gdzie są zainstalowane bazy oraz Firebird w poprzedniej wersji.

Po udanej migracji i aktualizacji na kolejnych stanowiskach wymieniamy tylko klienta RaksSQL o ile stanowisko nie korzysta z NetClienta. W przypadku instalacji za pomocą NetClienta nie ma potrzeby dokonywać aktualizacji.

Po wykonaniu migracji oraz konfiguracji serwera niezbędna jest aktualizacja RaksSQL o ile jest zainstalowany lokalnie na każdym stanowisku.

Jeżeli nie jest dokonywana aktualizacja RaksSQL to na końcówkach należy podmienić klienta Firebird 4.0. Są to pliki GDS32.dll , FBCLIENT.dll oraz GBAK.EXE

Instalacja klienta jest możliwa z tego samego pliku instalacyjnego Firebirda, z którego wcześniej wykonano instalację na serwerze, lub pobrane z katalogu Firebird/Bin na serwerze.

Jak usunąć usługę w systemie Windows 10, 8, 7

Opcja 1 – z wiersza poleceń CMD

Otwórz wiersz polecenia jako administrator .

Wpisz sc usuń. Następnie kliknij prawym przyciskiem myszy i wybierz Wklej , aby wprowadzić nazwę usługi. Jeśli nazwa usługi zawiera spacje, należy ją umieścić w cudzysłowie. Przykłady bez i ze spacją w nazwie to:

Użyj polecenia SC w ten sposób (musisz być w wierszu polecenia, aby wykonać polecenia w tym poście):

SC STOP shortservicename

SC DELETE shortservicename

Jeśli chcesz znaleźć skróconą nazwę usługi, użyj następującego polecenia, aby wygenerować plik tekstowy zawierający listę usług i ich statusy:

SC QUERY state= all >"C:\Service List.txt"

Aby uzyskać bardziej zwięzłą listę, wykonaj to polecenie:

SC QUERY state= all | FIND "_NAME"

Krótka nazwa usługi zostanie wyświetlona tuż nad wyświetlaną nazwą, w następujący sposób:

SERVICE_NAME: MyService

DISPLAY_NAME: My Special Service

Użyj polecenia SC w ten sposób (musisz być w wierszu polecenia, aby wykonać polecenia w tym poście):

SC STOP shortservicename (SC STOP MyService)

SC DELETE shortservicename (SC DELETE MyService)

Uwaga: Musisz uruchomić wiersz poleceń jako administrator, nie tylko zalogowany jako administrator, ale także z uprawnieniami administracyjnymi. Możesz to zrobić, wyszukując wiersz polecenia w menu Start, a następnie klikając prawym przyciskiem myszy i wybierając „Uruchom jako administrator”.

Opcja 2 – za pomocą rejestru systemowego Registry

Kliknij Start | Uruchom i wpisz regedit w wierszu Otwórz:. Kliknij OK.

Przejdź do gałęzi: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

W sekcji „ Usługi ” znajdują się foldery zawierające każdą usługę.

Wartości „DisplayName ” w każdym z tych folderów są równe nazwie usługi.

Przewiń w dół lewy panel, znajdź nazwę usługi, (przejrzyj listę lub użyj menu „ Edytuj ” > „ Znajdź ”, aby wyszukać usługę, którą chcesz usunąć) a następnie

kliknij ją prawym przyciskiem myszy i wybierz Usuń .

Uruchom ponownie system.

Sugerowana jest opcja pierwsza!

Informacje techniczne dodatkowe:

Firebird w wersji 4 (właściwie już w 3) nie jest w stanie odczytać baz danych z wersji 2.5 – zmieniła się struktura danych (ODS – on disk structure).

Ponadto zarzucono obsługę UDF (User Definied Function), w zamian rozbudowano listę wbudowanych funkcji.

Odstępstwo: można tworzyć funkcje, które nie sięgają do dodatkowego DLL-a, ale wykonują jakieś zapytanie/funkcję SQL.

Tabele systemowe

FB 4.0 nie dopuszcza jakichkolwiek modyfikacji tabel systemowych (RDB$*), można z nich wyłącznie czytać.

Złączenia

W przypadku łączenia w jednym zapytaniu wybierania za pomocą natural join (FROM tabela1, tabela1) oraz JOIN inaczej działa dostępność obiektów w zapytaniu.

Przykład zapytania, które nie zadziała na FB 4.0 (ale na 2.5 pójdzie):

SELECT *

FROM Tabela1 t1, Tabela2 t2

LEFT JOIN Tabela3 te on t3.id=t1.id_t3

Nie zadziała, ponieważ FB 4.0 traktuje inaczej bloki w sekcji FROM: najpierw wykona samo t1, a później t2 join t3.

W tej drugiej części nic nie wie o t1, użytej do warunku złączenia.

Powyższe zapytanie prawidłowo powinno wyglądać tak:

SELECT *

FROM (Tabela1 t1 LEFT JOIN Tabela3 te on t3.id=t1.id_t3), Tabela2 t2

Błędy mogące pojawić się po aktualizacji serwera:

– wrong or obsolete version. unsupported on-disk structure for file <nazwa pliku bazy danych>; found 11.2, support 13.0.

Nie wykonano aktualizacji baz, próba podłączenia nowego serwera bezpośrednio do starych baz. Silnik baz danych FB4.0, natomiast bazy w strukturze FB2.5.

Należy odtworzyć backup baz z poziomu Administrator – Odtwarzanie baz danych z kopii zapasowych

– Your user name and password are not defined. Ask your database administrator to set up a Firebird login.

Nie skonfigurowano poprawnie plików firebird.conf i database.conf. Należy skonfigurować je zgodnie z wytycznymi lub skopiować pliki, które zostały założone przy instalacji firebirda z instalatora Raksa (dotyczy FB4.0).

– Invalid BLR offset at… Function <nazwa funkcji> is not definied.

Bazę odtworzono za pomocą gbak, wobec czego nie zostały przekonwertowane odwołania do UDF ów. Należy odtworzyć bazy z poziomu Administrator – Odtwarzanie baz danych z kopii zapasowych.

– Unknown field type <nazwa typu pola>

Nie ustawiono w firebird.conf parametru DataTypeCompatibility = 2.5, wobec czego serwer odpowiada na zapytania używając nowych typów pól, czego nasz Raks nie jest w stanie obsłużyć.