Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: Adam F w Listopad 24, 2021, 08:45:28
-
Witam!
Uruchomiłem serwer mssql na Debian 11 dla Subiekt GT.
Cała instalacja serwera przebiegła poprawnie, bazę danych również udało się przerzucić i uruchomić.
Jednak jak się później okazało subiekt GT łączy się poprawnie tylko na jednym z trzech komputerów.
Na dwóch komputerach których nie da się połączyć z bazą danych wyskakuje komunikat:
'Nie można uzyskać połączenia z serwerem 192.168.1.103'
Jednak na tych samych komputerach bez problemu da się dostać do bazy danych z poziomu SQL Server Management Studio. Bez problemu program łączy się z serwerem i można pracować na bazie.
Podjęte próby:
Całkowite dezaktywowanie zapory systemu Windows - nie pomogło
-
Przeskanuj serwer z tych trzech kompów np. przy pomocy nmap i porównaj jakie porty widać serwera z tego kompa gdzie wszytko działa i z pozostałych. Jak jest zrobione uwierzytelnianie na serwerze w tych Subiektach GT - po Windows czy po koncie z MS SQL? Porty może blokować nie tylko firewall, ale np. mikrosegmentacja sieci czy antywirek. I to nie jest tak, że z MS SQL na Linuksie InsERT będzie działał bezproblemowo. Np. nie radzi sobie z ukośnikami w ścieżkach dostępu (w Linuksie są w przeciwną stronę niż w Windows) i jak ich ręcznie nie przerobisz na serwerze we właściwościach bazy, to nie przejdzie aktualizacji (ściślej pierwszą przejdzie, ale kolejnej nie, bo będzie miał \/ zamiast ukośników w ścieżkach...). Jak przerobisz, to aktualizację przejdzie, ale kopie po aktualizacji będą mieć skopane ścieżki. Z powodu tych ukośników InsERT nie potrafi wykasować "śmierci" po konwersji, więc będziesz musiał czyścić katalog temp na serwerze, by nie zapchać dysku. I albo musisz być szalony i udostępnić katalog roboczy wszystkim, albo musisz być guru z ustawiania praw dostępu albo musisz na serwerze postawić Sambę i w InsERT jako roboczy ustawić katalog sieciowy na roboczy, albo nie będzie działać Archiwizator. Będziesz się musiał nagimnastykować na Linuksie z ustawieniem zegara, bo Windows i Linux inaczej odczytują czas systemowy (Linux zakłada, że zegar systemowy jest UTC a Windows, że lokalny) albo będziesz miał przesunięty czas na dokumentach... Ale da się wszystko przeskoczyć i działa. :)
-
Dziękuję za szybką odpowiedz. Sprawdzę te porty i dam znać jak to wygląda.
Dodam jeszcze że mam aktualnie jeszcze jedną wersję serwera mssql na Debian 9 działającą na wszystkich komputerach(pod innym IP).
Przygotowywana przez osobę która się znała na tym. Jednak nie mam już do niej dostępu. Z tego drugiego adresu wszystko działa poprawnie.
Kopie zapasowe bazy danych są codziennie wykonywane 5 ostatnich dni. Dodatkowo jest wykonywana kopia każdego dnia na drugi serwer w innej lokalizacji.
Wszystko działa poprawnie.
-
Kopie zapasowe bazy danych są codziennie wykonywane 5 ostatnich dni. Dodatkowo jest wykonywana kopia każdego dnia na drugi serwer w innej lokalizacji.
Wszystko działa poprawnie.
Nie ma i nigdy nie było żadnych problemów z wykonywaniem kopii baz MS SQL na Linuksie. Problem jest tylko z Archiwizerem i Programem Narzędziowym i wykonywaniem aktualizacji (tworzą się kopie) w pakiecie InsERT gdy baza jest na MS SQL na Linuksie. To InsERT ma problem z Linuksem a nie MS SQL. MS SQL działa obojętnie czy w ścieżkach jest / czy \ a nawet działa jak jest \/ czy /\! ;)
-
Witam! Komputery przeskanowane za pomocą programu Nmap. Na tym na którym działa logowanie do Serwera jest tak samo jak i na tym na którym nie działa.
C:\Program Files (x86)\nmap>nmap.exe 192.168.1.103
Starting Nmap 7.92 ( https://nmap.org ) at 2021-11-27 16:17 îrodkowoeuropejski czas stand.
Nmap scan report for 192.168.1.103
Host is up (0.00057s latency).
Not shown: 995 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssn
445/tcp open microsoft-ds
1433/tcp open ms-sql-s
MAC Address: ... (Wistron)
Nmap done: 1 IP address (1 host up) scanned in 6.03 seconds
- Uwierzytelnianie jest zrobione po MS SQL
- Nie ma zastosowanej mikrosegmentacji sieci sieć składa się z 8 komputerów i nie ma takiej potrzeby
Tak jak pisałem inny serwer postawiony w 2017 roku działa bez zarzutu do dziś. Jednak chciałbym mieć zapasowy na wypadek ewentualnych problemów. Z wszystkich komputerów można się do niego dostać bez problemu.
-
Witam!
Uruchomiłem serwer mssql na Debian 11 dla Subiekt GT.
Cała instalacja serwera przebiegła poprawnie, bazę danych również udało się przerzucić i uruchomić.
Jednak jak się później okazało subiekt GT łączy się poprawnie tylko na jednym z trzech komputerów.
Na dwóch komputerach których nie da się połączyć z bazą danych wyskakuje komunikat:
'Nie można uzyskać połączenia z serwerem 192.168.1.103'
Jednak na tych samych komputerach bez problemu da się dostać do bazy danych z poziomu SQL Server Management Studio. Bez problemu program łączy się z serwerem i można pracować na bazie.
Podjęte próby:
Całkowite dezaktywowanie zapory systemu Windows - nie pomogło
Spróbuj w formularzu gdzie masz wprowadzony adres serwera na końcu dopisać po przecinku numer portu serwera czyli: 192.168.1.103, 1433
-
Witam! Dziękuję za odpowiedz.
Sprawdziłem opcję z podaniem portu: 192.168.1.103,1433
Niestety ale nadal nie działa.
Sytuacja wygląda następująco:
Sprawdziłem na tych komputerach gdzie nie działało i nadal nie działa.
Na komputerze gdzie działało - działa 192.168.1.103,1433 tak samo poprawnie jak 192.168.1.103
Dodatkowo
Ustawiłem stałe IP na serwerze ale nic to nie pomogło.
Również wyłączyłem serwer ten sprawny (192.168.1.102), a na tym nie do końca działającym ustawiłem adres 192.168.1.102 - nie działa
Dodam ponownie że z wszystkich komputerów można bez problemu połączyć się z bazą przy pomocy SQL Server Management Studio.
Niestety z poziomu subiekta czy programu serwisowego dla dwóch komputerów nie da się dla jednego da się.
-
Witam! Dziękuję za odpowiedz.
Sprawdziłem opcję z podaniem portu: 192.168.1.103,1433
Niestety ale nadal nie działa.
Sytuacja wygląda następująco:
Sprawdziłem na tych komputerach gdzie nie działało i nadal nie działa.
Na komputerze gdzie działało - działa 192.168.1.103,1433 tak samo poprawnie jak 192.168.1.103
Dodatkowo
Ustawiłem stałe IP na serwerze ale nic to nie pomogło.
Również wyłączyłem serwer ten sprawny (192.168.1.102), a na tym nie do końca działającym ustawiłem adres 192.168.1.102 - nie działa
Dodam ponownie że z wszystkich komputerów można bez problemu połączyć się z bazą przy pomocy SQL Server Management Studio.
Niestety z poziomu subiekta czy programu serwisowego dla dwóch komputerów nie da się dla jednego da się.
Jest na tej niedziałającej stacji jakiś antywirus ?
-
To jeszcze do głowy przychodzi mi brak odpowiedniej wersji Microsoft SQL Native Client i Backward Compatibility na tych windach klienckich. Sprawdź co masz zainstalowane i ew. spróbuj przeinstalować InsERTa z pełnej instalki (nie tej małej), to sobie powinien zaciągnąć z instalki co potrzebuje.
I jeszcze, ale to musiałby ktoś zaszaleć, ktoś tak skonfigurował firewalla czy MS SQL na serwerze, że akceptuje tylko połączenia ze wskazanych maszyn albo z wgranymi certyfikatami, ale to mało prawdopodobne.
-
Witam!
Próba przeinstalowania nic nie dała dalej brak połączenia dla tego jednego serwera, dra drugiego działa.
Jeszcze jedna nowa informacja się pojawiła.
Nawiązałem próbę połączenia z serwerem przy pomocy polecenia sqlcmd i dla tych komputerów nie działających otrzymałem taki komunikat.
Sqlcmd: Error: Microsoft ODBC Driver 11 for SQL Server: SSL Provider: Istniejące połączenie zostało gwałtownie zamknięte przez zdalnego hosta.
.
Sqlcmd: Error: Microsoft ODBC Driver 11 for SQL Server: Client unable to establish connection.
Dodam jeszcze że dla tego komputera na którym działa. Za pomocą tego polecenia również działa. Poprawnie nawiązał połączenie z bazą.
Dal serwera tego sprawnego z wszystkich komputerów nawiązano poprawne połączenie.
Dodam jeszcze że ten działający komputer jest z systemem Windows 10 a te nie działające z systemami Windows 8 i Windows 7.
-
Witam!
Bardzo dziękuję wszystkim za pomoc!:-)
Problem rozwiązany przynajmniej dla mnie.
Serwer działa z wszystkich komputerów poprawnie.
Problemem okazała się najnowsza wersja Debian 11.
Pod którą nie do końca wszystko działało.
Serwer uruchomiony na Debian 9 - śmiga.
Wyczytałem gdzieś że mssql server nie został jeszcze przygotowany i przetestowany pod Denian 11 i może wszystko nie działać tak jak należy.
Zainstalowałem starszą wersję i śmiga. Pewnie da się to jakoś ustawić jeśli dla jednego komputera działało poprawnie,
a z wszystkich dało się połączyć z bazą za pomocą SSMS, ale ja nie będę już tego rozkminiał.
Pozdrawiam wszystkich i raz jeszcze bardzo dziękuję za pomoc i zaangażowanie.
Adam