Migracja Firebird  2.5 do 4.0 dla biur rachunkowych         

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, 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ć operację.

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.

Migrację można potencjalnie robić na raty, oczywiście biorąc pod uwagę, żeby nie pracować na zdublowanych bazach. Jednakże zaleca się wykonanie migracji jednorazowo.

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

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/

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

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.

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.

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 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.

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”

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.

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 koro 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 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:  

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 dearchiwizacji 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 te 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.

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
  • zainstalowanie Firebird 4.0
  • modyfikacja pliku konfiguracyjnego firebird.conf (w miejscu instalacji Firebird)
  • modyfikacja pliku konfiguracyjnego databases.conf (w miejscu instalacji Firebird)
  • restart lub uruchomienie usługi Firebird
  • wymiana bibliotek klienta w lokalizacji Raks/Bin jeżeli nie była robiona aktualizacja

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).

Archiwizacja i dearchiwizacja za pomocą GBAK.EXE:

Wykonanie kopii zapasowej oraz przywrócenie z niej danych (backup/restore) 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 -b {host/path}{nazwa_pliku}.fdb {host/path}{nazwa_pliku}.fbk -user sysdba -pas masterkey

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

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

  • odinstalowanie Firebird 2.5
  • zainstalowanie Firebird 4.0
  • modyfikacja pliku konfiguracyjnego firebird.conf (w miejscu instalacji Firebird)
  • modyfikacja pliku konfiguracyjnego databases.conf (w miejscu instalacji Firebird)
  • restart lub uruchomienie usługi Firebird (zmiana parametrów firebird.conf będzie uwzględniona przez serwer po jego zatrzymaniu i ponownym uruchomieniu)
  • wymiana bibliotek klienta w lokalizacji Raks/Bin jeżeli nie była robiona aktualizacja

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).

odinstalowanie serwera Firebird 2.x oraz instalacja serwera Firebird 3.0

Program instalacyjny powinien być uruchomiony jako administrator (prawy przycisk myszy na instalatorze „Uruchom jako administrator”), pozwoli to uniknąć późniejszych problemów.

Firebird 4.0 należy zainstalować jako usługa w wersji SuperClasicServer z zaznaczoną opcją kopiowania biblioteki GDS32.dll.

Wersję instalacyjną serwera Firebird można pobrać ze strony: https://www.firebirdsql.org/ .      Należy wybrać 64 bitową wersję serwera.

Skopiowanie baz na Firebird 2.5 komenda:

gbak -b -g -V -user <username> -pas <password> -se <service>

<database> <backup_file> -Y <log_file>

Odtworzenie baz na Firebird 4 komenda:

gbak -c -v -user <username> -pas <password> -se <service>

<backup_file> <database_file> -Y <log_file>

gbak -c {host/path}{nazwa_pliku}.fbk {host/path}{nazwa_pliku}.fdb -user sysdba -pas masterkey

Przykład

gbak -c C:\Kopia\1234567.fbk C:\Bazy\1234567.fdb -user sysdba -pas masterkey

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

Po tej czynności cały proces migracji i aktualizacji zostaje zakończony.

System jest sprawny, działający, w nowszej wersji a bazy danych zarządzane na nowym Firebirdzie 4.0

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:                                                            

FB 4.0 nie ma UDF-ów, w zmiana dostał rozbudowana listę funkcji wbudowanych. Teoretycznie da się wymusić uruchomienie UDF, ale widać, że jest to funkcjonalność schyłkowa i lepiej się w to nie pchać.

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