Disconnect from Server

Disconnect from Server to polecenie zamykające aktywne połączenie z instancją serwera SQL z poziomu narzędzia zarządzającego.

Disconnect from Server w narzędziu do obsługi SQL

Disconnect from Server to funkcja dostępna w narzędziach administracyjnych i deweloperskich służących do pracy z bazami danych SQL. Jej zadaniem jest zakończenie bieżącej sesji ustanowionej pomiędzy aplikacją zarządzającą a wybraną instancją systemu bazodanowego. Polecenie nie usuwa instancji, nie zatrzymuje usługi i nie wyłącza komputera, na którym działa silnik bazy danych. Rozłącza jedynie aktualny kontekst pracy po stronie używanego programu.

W praktyce opcja może pojawić się w menu kontekstowym nazwy serwera, w menu połączenia albo w pasku narzędzi. Po jej wybraniu program zamyka kanał komunikacyjny, a elementy interfejsu zależne od aktywnej sesji mogą stać się nieaktywne. Dotyczy to między innymi eksploratora obiektów, podglądu baz, list tabel, procedur, widoków oraz innych składników zależnych od dostępności połączenia. Sam serwer nadal może działać i obsługiwać inne aplikacje oraz użytkowników.

Rozłączenie jest przydatne po zakończeniu prac administracyjnych, testów zapytań, konfiguracji uprawnień albo przeglądania struktury bazy. Pozwala również uporządkować środowisko pracy, gdy otwarto kilka sesji do różnych instancji i nie ma już potrzeby utrzymywania każdej z nich. W wielu programach czynność ta stanowi bezpieczniejszy odpowiednik zamknięcia całej aplikacji, ponieważ zamykany jest tylko wskazany kontekst połączenia.

Disconnect from Server a sesja, zapytanie i transakcja

Warto rozdzielić kilka pojęć, które w codziennej pracy bywają traktowane jako jedno. Sesja oznacza logiczny stan komunikacji pomiędzy klientem a silnikiem bazy danych. Połączenie jest technicznym kanałem, za pośrednictwem którego przesyłane są polecenia i odbierane wyniki. Edytor zapytań jest natomiast miejscem, w którym wpisuje się instrukcje SQL. Funkcja Disconnect from Server dotyczy przede wszystkim komunikacji klienta z instancją, a nie samej treści dokumentu otwartego w edytorze.

Rozłączenie nie jest tym samym co anulowanie zapytania. Jeżeli zapytanie nadal się wykonuje, reakcja programu może zależeć od używanego narzędzia, rodzaju operacji oraz momentu, w którym wybrano funkcję. W jednym przypadku wykonywanie zostanie przerwane, w innym aplikacja najpierw zaczeka na odpowiedź albo wyświetli komunikat o trwającej operacji. Przy długich poleceniach lepiej korzystać z funkcji zatrzymania lub anulowania zapytania, jeżeli jest dostępna, a dopiero później zamykać sesję.

Odrębne znaczenie ma transakcja. Jeżeli wykonano polecenia modyfikujące dane w ramach transakcji, rozłączenie może spowodować wycofanie zmian, gdy nie zostały one zatwierdzone. Zachowanie zależy od ustawień, sterownika, aplikacji oraz sposobu obsługi transakcji przez silnik. Przed użyciem Disconnect from Server należy sprawdzić, czy operacja została zatwierdzona i czy nie pozostaje otwarty proces wymagający dalszej pracy. W przypadku zmian strukturalnych lub masowych modyfikacji wskazane jest odczekanie na zakończenie działania i potwierdzenie rezultatu.

Nie należy utożsamiać tej funkcji z poleceniem wylogowania wszystkich użytkowników. Rozłączenie z poziomu jednego narzędzia oddziałuje na jego własną sesję. Inne programy korzystające z tej samej instancji pozostają podłączone, o ile nie zastosowano osobnych działań administracyjnych.

Disconnect from Server i porównanie z zamknięciem programu

Zamknięcie aplikacji zarządzającej zwykle kończy wszystkie połączenia należące do tego programu. Disconnect from Server pozwala wybrać konkretną sesję i pozostawić resztę środowiska otwartą. Jest to szczególnie wygodne podczas pracy z kilkoma źródłami danych, kiedy jedna sesja ma zostać zakończona, ale edytor, dokumentacja lub inne połączenie nadal są potrzebne.

Występuje też różnica między rozłączeniem a przełączeniem na inną instancję. Przy zmianie połączenia program może samodzielnie zamknąć poprzednią sesję i otworzyć nową, ale nie zawsze przebiega to w identyczny sposób jak ręczne wybranie Disconnect from Server. W zależności od aplikacji mogą pozostać otwarte zakładki zapytań, zapisane ustawienia, historia poleceń albo lokalny cache metadanych. Obecność tych elementów nie oznacza, że sesja nadal jest aktywna.

Inaczej działa również ponowne połączenie. Po wybraniu opcji Connect program próbuje ustanowić nową sesję, ponownie sprawdzając nazwę instancji, sposób uwierzytelniania, dostępność sieci oraz uprawnienia konta. Zapisane zapytanie może nadal znajdować się w edytorze, lecz jego wykonanie wymaga aktywnego połączenia. Dlatego przy diagnozowaniu problemu należy rozdzielić błąd samego zapytania od komunikatu informującego o braku sesji.

W środowiskach, w których używa się wielu profili połączeń, pomocne jest jednoznaczne opisywanie zakładek i dokumentów. Ogranicza to ryzyko wpisania polecenia w niewłaściwym oknie po ponownym połączeniu. Przed wykonaniem modyfikacji warto sprawdzić nazwę instancji, wybraną bazę oraz konto widoczne w pasku stanu narzędzia.

Typowe problemy po użyciu Disconnect from Server

Najczęściej pojawiający się komunikat po rozłączeniu informuje, że nie istnieje aktywne połączenie albo że nie można wykonać operacji bez połączenia. Taki komunikat jest spodziewanym skutkiem użycia funkcji i nie musi oznaczać awarii silnika SQL. Wystarczy nawiązać sesję ponownie, o ile znane są prawidłowe dane połączenia i użytkownik ma wymagane uprawnienia.

Inny przypadek występuje wtedy, gdy po ponownym połączeniu narzędzie nie odświeża listy obiektów. W pamięci programu mogą pozostawać wcześniejsze informacje o bazach, tabelach lub procedurach, dlatego widok powinien zostać odświeżony ręcznie. Gdy obiekt zniknął albo pojawił się dopiero po zmianie, lokalny widok może przez pewien czas prezentować nieaktualne dane. Odświeżenie nie zmienia danych w bazie, lecz pobiera ponownie metadane.

Problemy z ponownym połączeniem mogą wynikać z niedostępności usługi, błędnej nazwy instancji, niewłaściwego portu, niedziałającego mechanizmu uwierzytelniania, reguł zapory albo utraty połączenia sieciowego. Znaczenie ma także to, czy używany jest dostęp lokalny, połączenie zdalne, tunel lub dodatkowa warstwa pośrednia. Samo ponowne klikanie przycisku Connect nie rozwiąże problemu, jeżeli przyczyna leży poza aplikacją.

Jeżeli rozłączenie następuje samoistnie, należy zwrócić uwagę na czas wystąpienia zdarzenia, rodzaj wykonywanej operacji oraz komunikat zapisany w dzienniku programu. Przydatne bywa sprawdzenie, czy problem pojawia się tylko w jednym narzędziu, czy również w innych klientach SQL. Warto także ustalić, czy rozłączane są wszystkie sesje, czy tylko jedna. Takie informacje ułatwiają odróżnienie problemu z aplikacją od przerwy w komunikacji lub zmian po stronie usługi bazodanowej.

Kiedy Disconnect from Server wymaga ostrożności

Przed zakończeniem sesji powinno się sprawdzić, czy nie trwa import, eksport, aktualizacja danych, przebudowa indeksu albo inna operacja, której przerwanie może pozostawić proces w stanie pośrednim. Nie każda czynność zostanie cofnięta w ten sam sposób. Długa operacja może nadal działać po stronie silnika, mimo że interfejs klienta utracił połączenie, dlatego po ponownym zalogowaniu warto potwierdzić jej stan zamiast uruchamiać ją ponownie bez sprawdzenia.

Ostrożność jest potrzebna także przy wielu otwartych zakładkach. Zamknięcie sesji może uniemożliwić wykonanie polecenia znajdującego się w edytorze, a po ponownym połączeniu kontekst bazy może być inny niż wcześniej. Przed kontynuacją należy zweryfikować bieżącą bazę, konto i zakres uprawnień. Przy pracy na danych produkcyjnych wskazane jest zachowanie zapytania, zapisanie komunikatów oraz odnotowanie momentu rozłączenia.

Jeżeli Disconnect from Server jest wybierane przypadkowo, sesja regularnie znika albo aplikacja nie pozwala na ponowne połączenie, można zgłosić problem do serwisu komputerowego. Warszawskie Pogotowie Komputerowe 24/7 wykonuje naprawy z reguły do 3 dni roboczych, dlatego przy zgłoszeniu warto przekazać nazwę używanego programu, dokładny komunikat, informacje o momencie wystąpienia problemu oraz opis ostatniej wykonywanej operacji. Tak przygotowane dane ułatwiają ocenę, czy przyczyną jest konfiguracja klienta, dostęp do usługi, sieć, system operacyjny czy sposób obsługi sesji SQL.

W codziennej pracy Disconnect from Server powinno być traktowane jako kontrolowane zakończenie konkretnej sesji, a nie jako metoda naprawy każdego problemu z bazą. Prawidłowe rozpoznanie różnicy między utratą połączenia, anulowaniem zapytania, wycofaniem transakcji i zamknięciem aplikacji pozwala uniknąć niepotrzebnych powtórzeń operacji oraz ułatwia dalszą diagnostykę.