Czy Subiekt GT współpracuje z SQL Server na Linuxie?

Migrację Subiekta GT na nowy komputer albo nowy serwer wykonujemy jako element naprawy albo modernizacji sprzętu — obejmuje to przeniesienie bazy danych SQL Server i ponowną konfigurację połączenia sieciowego.

Czy Subiekt GT współpracuje z SQL Server na Linuxie

Subiekt GT jest programem przeznaczonym do pracy z bazą danych Microsoft SQL Server, dlatego samo uruchomienie systemu Linux nie oznacza automatycznie, że można bezpośrednio zainstalować na nim pełne środowisko wymagane przez aplikację. Należy rozdzielić dwie kwestie: system operacyjny, na którym działa program Subiekt GT, oraz system, na którym znajduje się baza danych. W typowej konfiguracji aplikacja kliencka działa w środowisku Windows, natomiast baza może być udostępniana z innego komputera przez sieć.

SQL Server posiada wydania przeznaczone dla systemu Linux, jednak zgodność konkretnej wersji serwera z Subiektem GT nie powinna być przyjmowana wyłącznie na podstawie faktu, że oba rozwiązania korzystają z technologii SQL. Znaczenie mają między innymi obsługiwane wersje silnika bazy, sterowniki komunikacyjne, sposób uwierzytelniania, ustawienia połączeń oraz mechanizmy wykorzystywane przez program podczas tworzenia i odczytu danych. Wymagana jest również weryfikacja, czy producent Subiekta GT przewidział daną konfigurację jako wspieraną.

W praktyce spotykane są rozwiązania, w których baza SQL Server pozostaje na komputerze z systemem Windows, a stanowiska użytkowników łączą się z nią przez sieć lokalną. Możliwe jest także rozważenie układu mieszanego, w którym SQL Server pracuje na Linuxie, a Subiekt GT uruchamiany jest na komputerach Windows. Taki wariant wymaga jednak dokładnych testów, odpowiedniej konfiguracji komunikacji oraz przygotowania procedury tworzenia i odtwarzania kopii zapasowych. Nie powinno się przenosić środowiska produkcyjnego tylko dlatego, że technicznie możliwe jest uruchomienie określonego komponentu na innym systemie.

Różnica między uruchomieniem programu a dostępem do bazy

Najczęściej nieporozumienie wynika z utożsamiania Subiekta GT z samym serwerem bazy danych. Program pełni funkcję aplikacji użytkowej, natomiast SQL Server przechowuje informacje o kartotekach, dokumentach, kontrahentach, stanach magazynowych i ustawieniach pracy. Te elementy mogą znajdować się na różnych urządzeniach, ale muszą komunikować się w sposób zgodny z wymaganiami programu.

Przy analizie konfiguracji należy sprawdzić, czy komputer z Subiektem GT potrafi nawiązać połączenie z instancją SQL Server, czy używany port jest dostępny, czy zapora sieciowa nie blokuje ruchu oraz czy nazwa serwera i instancji zostały podane prawidłowo. Istotne jest także ustalenie, czy połączenie odbywa się z wykorzystaniem kont systemowych, czy osobnych danych logowania do SQL Server. Błędne ustawienie dowolnego z tych elementów może powodować komunikaty sugerujące uszkodzenie bazy, mimo że problem dotyczy wyłącznie komunikacji.

Nie bez znaczenia pozostaje sposób instalacji i aktualizacji. Zmiana systemu operacyjnego, przeniesienie danych albo wymiana komputera może wymagać odtworzenia bazy, ponownego wskazania serwera, skonfigurowania usług oraz sprawdzenia dostępu z każdego stanowiska. Przed zmianą zaleca się wykonanie sprawdzonej kopii zapasowej, zapisanie bieżących parametrów połączenia i przeprowadzenie próby odtworzenia danych w środowisku testowym.

Typowe problemy przy połączeniu Subiekta GT z SQL Server na Linuxie

Jednym z częstszych problemów jest brak jednoznacznego potwierdzenia, że dana wersja Subiekta GT, sterownika i SQL Server może współpracować w wybranym układzie. Nawet jeśli sam silnik bazy uruchamia się poprawnie na Linuxie, aplikacja może wymagać określonych funkcji, bibliotek albo sposobu obsługi połączenia. W takiej sytuacji pomocne jest porównanie wersji wszystkich składników oraz sprawdzenie dokumentacji producenta.

Problemy mogą wynikać również z konfiguracji sieciowej. Błędny adres hosta, wyłączona usługa SQL Server Browser, nieotwarty port, nieprawidłowa nazwa instancji lub reguły zapory mogą uniemożliwić zalogowanie do bazy. Jeżeli połączenie działa tylko na jednym komputerze, a pozostałe stanowiska zgłaszają błąd, należy porównać ich ustawienia, rozwiązywanie nazw i dostęp do zasobów sieciowych.

Odrębną kategorię stanowią problemy z kodowaniem znaków, sortowaniem danych, uprawnieniami i kompatybilnością dodatków. W bazie handlowej znaczenie ma prawidłowe wyświetlanie polskich znaków, kolejność sortowania oraz możliwość wykonywania operacji przez poszczególne konta. Należy także zachować ostrożność przy bezpośredniej edycji tabel. Dane Subiekta GT powinny być modyfikowane z poziomu programu, a ingerencja w bazę bez znajomości jej struktury może doprowadzić do niespójności dokumentów lub utraty części informacji.

Przed przełączeniem użytkowników na nową konfigurację warto sprawdzić logowanie, otwieranie kartotek, wystawianie dokumentów, pracę magazynu, wydruki, eksporty oraz tworzenie kopii zapasowej. Sam fakt, że program się uruchamia, nie potwierdza jeszcze poprawności całego środowiska.

Kiedy warto zgłosić konfigurację do serwisu - Czy Subiekt GT współpracuje z SQL Server na Linuxie

Wsparcie serwisowe jest zasadne, gdy po przeniesieniu bazy pojawia się błąd połączenia, program nie widzi danych, stanowiska tracą dostęp do wspólnej kartoteki albo planowana jest zmiana komputera i sposobu przechowywania bazy. W takiej sytuacji można zlecić sprawdzenie zgodności komponentów, przygotowanie kopii bezpieczeństwa, odtworzenie danych, konfigurację dostępu sieciowego oraz test podstawowych funkcji Subiekta GT.

W Warszawie takie prace można przekazać do Warszawskiego Pogotowia Komputerowego 24/7, gdzie przed rozpoczęciem właściwych czynności ustala się zakres problemu i stan używanego środowiska. Szczególnie ważne jest przekazanie informacji o wersji Subiekta GT, dotychczasowym miejscu przechowywania bazy, systemie operacyjnym oraz komunikacie pojawiającym się podczas logowania. Pozwala to ograniczyć ryzyko pochopnej migracji i dobrać sposób postępowania do rzeczywistej konfiguracji.

Jeżeli baza zawiera dane bieżącej sprzedaży, magazynu lub rozliczeń, nie powinno się wykonywać eksperymentalnych zmian bez kopii zapasowej i planu powrotu do poprzedniego stanu. Najbezpieczniej najpierw potwierdzić zgodność rozwiązania na kopii roboczej, a dopiero później przenosić użytkowników do nowego układu. Dzięki temu można rozdzielić problem programu, bazy, sieci i systemu operacyjnego, zamiast traktować każdy błąd jako uszkodzenie danych.