Konfiguracja pracy wielostanowiskowej w Subiekcie GT

Kilka osób w jednym programie

Praca wielostanowiskowa wymaga poprawnie skonfigurowanej sieci i uprawnień. Bez tego pracownicy zaczynają sobie nawzajem przeszkadzać: dokumenty blokują się wzajemnie, numeracja się rozjeżdża, a program zwalnia bez wyraźnego powodu.

Co konfigurujemy

• Serwer bazy danych i dostęp do niego z poszczególnych stanowisk.
• Stały adres serwera, żeby połączenie nie znikało po zmianach w sieci.
• Osobne konta użytkowników z uprawnieniami odpowiadającymi stanowiskom.
• Numerację dokumentów rozdzieloną tak, żeby stanowiska nie kolidowały.
• Ustawienia zapory na serwerze i na stanowiskach.

Najczęstsza przyczyna spowolnień

Nie liczba użytkowników, tylko sieć. Serwer podłączony przez słabe łącze bezprzewodowe albo przez uszkodzony przewód dławi pracę wszystkim naraz. Przy programach pracujących na bazie danych połączenie przewodowe to nie zalecenie, tylko warunek sensownej pracy.

Blokady dokumentów

Dwie osoby edytujące ten sam dokument to sytuacja, którą program musi rozstrzygnąć — i rozstrzyga ją blokadą. Częste blokady wskazują zwykle nie na błąd, lecz na organizację pracy: brak podziału obowiązków albo wspólne konto używane przez kilka osób.

Praca zdalna ze stanowiskiem

Bezpośrednie połączenie z bazą przez internet działa niestabilnie i bywa niebezpieczne. Sensowniejszy jest pulpit zdalny wewnątrz tunelu VPN — program pracuje wtedy blisko bazy, a przez sieć idzie tylko obraz.

Po konfiguracji

Sprawdzamy pracę przy pełnym obciążeniu, ze wszystkimi stanowiskami jednocześnie — a nie po kolei.

Jak działa układ serwer i stanowiska

Subiekt GT przechowuje dane w bazie obsługiwanej przez Microsoft SQL Server, czyli system zarządzający wspólnym zbiorem dokumentów, kartotek i ustawień. Stanowiska robocze nie powinny mieć osobnych kopii aktualnych danych. Każde z nich łączy się z tą samą bazą na wybranym komputerze lub serwerze. Dzięki temu wystawiony dokument, zmiana stanu magazynowego albo nowy kontrahent stają się dostępne dla pozostałych uprawnionych użytkowników.

Komputer pełniący rolę serwera musi być dostępny w godzinach pracy pozostałych stanowisk. Nie powinien przechodzić w uśpienie ani otrzymywać przypadkowo innego adresu w sieci. Stały adres można zapewnić przez ustawienie urządzenia albo rezerwację DHCP, czyli przypisanie przez router zawsze tego samego adresu do konkretnej karty sieciowej. Istotna jest również zgodność nazwy instancji, czyli wskazania konkretnego środowiska SQL Server, z konfiguracją zapisaną na stanowiskach.

Różne warianty problemów wielostanowiskowych

Jeżeli tylko jedno stanowisko nie widzi bazy, przyczyny należy szukać przede wszystkim na tym komputerze. Może to być błędna nazwa serwera, profil sieci ustawiony jako publiczny, reguła zapory albo problem z rozpoznawaniem nazwy urządzenia. Profil publiczny to bardziej restrykcyjny zestaw zasad Windows, który ogranicza komunikację z innymi komputerami w lokalnej sieci.

Gdy wszystkie stanowiska tracą połączenie jednocześnie, sprawdzenia wymaga serwer, usługa SQL Server oraz wspólna infrastruktura sieciowa. Usługa to proces działający w tle i udostępniający bazę programowi. Jej zatrzymanie powoduje, że baza pozostaje na dysku, ale stanowiska nie mogą z niej korzystać. Podobny skutek może mieć wyłączenie serwera, zmiana jego adresu albo awaria routera lub przełącznika sieciowego.

Jeżeli program działa szybko na serwerze, a wolno na każdym innym komputerze, źródłem problemu często jest droga pomiędzy urządzeniami. Weryfikuje się wtedy przewody, porty przełącznika oraz stabilność transmisji. Sam dostęp do internetu nie rozstrzyga o jakości sieci lokalnej. Internet może działać prawidłowo, a wymiana danych z bazą nadal może być niestabilna.

Inny wariant występuje wtedy, gdy spowolnienie dotyczy tylko określonych operacji, na przykład wyszukiwania w dużej kartotece albo tworzenia zestawienia. W takim przypadku należy odróżnić problem sieciowy od obciążenia serwera, stanu bazy oraz sposobu wykonywania konkretnej operacji. Jedna przyczyna nie wyjaśnia automatycznie każdego rodzaju opóźnienia.

Uprawnienia powinny wynikać z obowiązków

Wspólne konto dla kilku osób utrudnia ustalenie, kto wykonał daną operację. Zwiększa także zakres skutków pomyłki, ponieważ każdy użytkownik otrzymuje te same możliwości. Bezpieczniejszy jest podział na osobne konta oraz nadanie dostępu zgodnie z rzeczywistymi zadaniami. Pracownik wystawiający dokumenty sprzedaży nie zawsze potrzebuje uprawnień do ustawień administracyjnych, zmian konfiguracji albo wszystkich danych finansowych.

Przydzielanie uprawnień warto rozpocząć od opisania ról, na przykład sprzedaży, magazynu, księgowości i administratora. Rola oznacza zestaw czynności związanych z konkretnym stanowiskiem pracy. Dopiero na tej podstawie konfiguruje się możliwości użytkowników. Ograniczenia nie powinny jednak blokować typowych zadań, dlatego po zmianach sprawdza się cały przebieg pracy, a nie wyłącznie samo uruchomienie programu.

Osobne konta pomagają również przy blokadach. Można wtedy ustalić, na którym stanowisku dokument pozostał otwarty. Należy najpierw sprawdzić, czy użytkownik nadal nad nim pracuje. Wymuszone przerywanie sesji, czyli aktywnego połączenia programu z bazą, bez takiego sprawdzenia może spowodować utratę niezapisanych zmian.

Numeracja dokumentów przy kilku stanowiskach

Sposób numerowania powinien odpowiadać organizacji sprzedaży i obiegu dokumentów. W części firm wystarcza jedna wspólna numeracja, ponieważ program przydziela kolejne numery podczas zapisu. W innych potrzebne są odrębne serie związane na przykład z oddziałem, magazynem albo rodzajem sprzedaży. Seria numeracji to oznaczenie pozwalające rozdzielić dokumenty należące do różnych procesów.

Nie należy tworzyć dodatkowych serii wyłącznie po to, aby ukryć problem z jednoczesną pracą. Najpierw trzeba ustalić, czy kolizja wynika z konfiguracji, sposobu zapisu dokumentów czy przyjętej organizacji. Zmiana schematu numeracji wpływa na późniejsze wyszukiwanie, wydruki i pracę księgowości, dlatego wymaga uzgodnienia z osobami korzystającymi z dokumentów.

Błędy podczas samodzielnej konfiguracji

Częstym błędem jest udostępnienie w Windows folderu z plikami programu i uznanie, że w ten sposób udostępniono bazę. Subiekt GT komunikuje się z usługą SQL Server, a nie pracuje na zwykłym dokumencie otwieranym ze współdzielonego katalogu. Sam dostęp do folderu nie zastępuje poprawnego połączenia z serwerem bazy.

Nie należy także wyłączać całej zapory systemowej, aby sprawdzić połączenie. Zapora filtruje ruch sieciowy i ogranicza dostęp do usług. Prawidłowe rozwiązanie polega na przygotowaniu potrzebnych reguł dla właściwego profilu sieci, a nie na trwałym usunięciu ochrony. Zbyt szeroka reguła może udostępnić usługę również w sieci, której nie uznaje się za zaufaną.

Kolejnym problemem jest ręczne kopiowanie plików bazy między komputerami. Taka kopia nie tworzy pracy wielostanowiskowej, lecz kilka niezależnych wersji danych. Dokument wystawiony w jednej wersji nie pojawi się automatycznie w drugiej. Przywracanie kopii bezpieczeństwa również wymaga kontroli, ponieważ może zastąpić nowsze dane starszym stanem.

Nie warto usuwać blokad przez restartowanie serwera bez sprawdzenia aktywnych użytkowników. Restart rozłącza wszystkie stanowiska i przerywa wykonywane operacje. Najpierw ustala się, czy blokada jest prawidłowym skutkiem edycji, czy pozostałością po zerwanym połączeniu. Dopiero potem wybiera się sposób bezpiecznego zakończenia sesji.

Kiedy spowolnienie nie wynika z sieci

Powolne działanie może mieć źródło w samym serwerze. Znaczenie ma dostępność pamięci operacyjnej, obciążenie procesora oraz stan nośnika, na którym pracuje baza. Pamięć operacyjna to przestrzeń używana przez uruchomione programy, a przeciążony nośnik wydłuża odczyt i zapis danych. Jeżeli komputer serwerowy równocześnie wykonuje wiele innych zadań, Subiekt GT może reagować wolniej mimo prawidłowego połączenia przewodowego.

Problem może również dotyczyć konkretnego stanowiska. Programy ochronne skanujące intensywnie pliki, zaległe aktualizacje systemu, mała ilość wolnego miejsca albo inne procesy działające w tle mogą wpływać na jego pracę. Jeżeli pozostałe komputery działają poprawnie, nie ma podstaw, aby od razu przebudowywać całą sieć.

Blokada pojedynczego dokumentu także nie musi oznaczać awarii bazy. Może być zamierzonym mechanizmem chroniącym dane przed równoczesną, sprzeczną zmianą. O usterce można mówić dopiero wtedy, gdy blokada pozostaje mimo zakończenia pracy na drugim stanowisku albo regularnie pojawia się po zerwaniu połączenia.

Kopie bezpieczeństwa w środowisku wielostanowiskowym

Wspólna baza oznacza, że awaria serwera dotyczy wszystkich stanowisk. Z tego powodu kopia bezpieczeństwa powinna obejmować właściwą bazę i być wykonywana w kontrolowany sposób. Samo skopiowanie skrótu do programu lub katalogu instalacyjnego nie zabezpiecza dokumentów handlowych. Kopia musi być także okresowo sprawdzana pod kątem możliwości odtworzenia.

Plik kopii nie powinien pozostawać wyłącznie na tym samym nośniku co baza. Awaria dysku, zaszyfrowanie danych albo uszkodzenie systemu mogłyby wtedy objąć zarówno dane robocze, jak i ich jedyne zabezpieczenie. Miejsce przechowywania oraz dostęp do kopii dobiera się z uwzględnieniem poufności danych firmy.

Dodatkowe pytania o pracę na wielu stanowiskach

Czy każde stanowisko musi mieć przewód sieciowy?

Dla komputerów stale pracujących z bazą zalecane jest stabilne połączenie przewodowe. Sieć bezprzewodowa może działać poprawnie, lecz jest bardziej podatna na zakłócenia, zmianę zasięgu i krótkie przerwy. Zerwanie połączenia podczas zapisu jest poważniejszym problemem niż samo wolniejsze otwieranie okna programu.

Czy można pracować na laptopie poza biurem?

Taką pracę należy zorganizować przez bezpieczny dostęp do komputera znajdującego się blisko bazy. Pulpit zdalny pozwala obsługiwać ten komputer na odległość, natomiast VPN tworzy szyfrowany tunel pomiędzy urządzeniem zdalnym a siecią firmową. Nie należy wystawiać usługi bazy bezpośrednio do internetu.

Czy jeden użytkownik może być zalogowany na dwóch komputerach?

Techniczna możliwość nie oznacza, że jest to dobry sposób organizacji pracy. Wspólna tożsamość utrudnia rozpoznanie autora operacji i analizę blokad. Dla osób wykonujących oddzielne zadania powinny istnieć osobne konta z odpowiednimi uprawnieniami.

Czy po dodaniu stanowiska wystarczy sprawdzić logowanie?

Nie. Test powinien objąć otwieranie kartotek, zapis dokumentów, drukowanie, dostęp do wymaganych magazynów oraz równoczesną pracę z innymi stanowiskami. W ten sposób można wychwycić problem widoczny dopiero podczas rzeczywistej wymiany danych albo przy określonym poziomie uprawnień.

Czy do konfiguracji potrzebne jest hasło użytkownika Windows?

Domyślnie nie prosi się o hasło. Jeżeli konkretna czynność administracyjna wymaga uwierzytelnienia, najpierw wyjaśnia się jej cel i zakres. Dostęp powinien być ograniczony do tego, co jest niezbędne do wykonania konfiguracji.

Odbiór konfiguracji bez niespodzianek przy pierwszym wspólnym dniu pracy

Końcowa weryfikacja powinna odtwarzać rzeczywisty przebieg pracy: równoczesne logowanie, obsługę różnych typów dokumentów, wyszukiwanie kartotek i wykonywanie wydruków. Sprawdza się też zachowanie po ponownym uruchomieniu serwera oraz stanowisk. Dobrze skonfigurowane środowisko wielostanowiskowe poznaje się nie po tym, że program otworzył się na każdym komputerze, lecz po tym, że wspólna baza pozostaje dostępna, uprawnienia odpowiadają obowiązkom, a codzienne operacje nie wymagają obchodzenia konfiguracji.