Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: tomson5 w Listopad 04, 2016, 15:34:10
-
Witam
Nie mogę przeprowadzić aktualizacji podmiotu. W raporcie otrzymuję taką informację.
Kompaktowanie podmiotu...Nie powiodło się:
Błąd 0x80004005: Nieokreślony błąd.
Aktualizacja podmiotu nie powiodła się: 0x80004005: Nieokreślony błąd.
Nie powiodło się przełączanie baz: z firma_kopia na firma z powodu błędu: Only user processes can be killed.
Przywrócenie podmiotu nie udało się.
Może ktoś spotkał się z takim problemem??
-
Spróbuj skompaktować podmiot przed konwersją, jeśli nie uda się za pomocą programu serwisowego to zrób to za pomocą SSMS.
-
Robiłem kompaktowanie przed ale aktualizacja kończyła się podobnie. Błąd przy przełączaniu baz.
-
Robiłem kompaktowanie przed ale aktualizacja kończyła się podobnie.
W jaki sposób ?
Błąd przy przełączaniu baz.
To bez znaczenia, problem przecież pojawia się wcześniej.
--
Sprawdź czy baza danych nie jest uszkodzona.
-
Miałem takie przypadki. Jesli z pomocą SSMS ustawi się prawidłowe parametry bazy, to baza się uruchomi bez problemu.
Sprawdzałem takie bazy i nie wykazywały żadnych uszkodzeń ani niespójności, następne konwersje przebiegały bez problemu i pracują do dziś.
Taki objaw obserwuję od wersji chyba 1.42.
-
Napiszę od początku.
Na starym laptopie z XP mam sql server 2008 r2 i subiekta GT Działa to dobrze i nigdy nie było potrzeby instalowania ssms.
Nastąpiła potrzeba zmiany sprzętu i systemu na W10
Zainstalowałem sql server 2008 r2 i subiekta GT Poz dearchiwizacji do podmiotu uruchomiłem subiekta i wybrałem utworzony podmiot i działało. Wystąpił problem z logowaniem z innego komputera. Okazało się że brak użytkownika sa. Zmuszony zostałem do zainstalowania ssms i za jego pomocą utworzyłem konto sa i problem załatwiony aż do czasu nowej aktualizacji z którą tak jak teraz nie mogłem sobie poradzić.
Zrezygnowany odpaliłem starego laptopa z XP który działał dobrze i na nim przeprowadziłem proces aktualizacji programu a później bazy. Otrzymany plik archiwizacji przeniosłem do nowego laptopa i po dearchiwizacji wszystko ruszyło. Nie mogę ciągle jednak działać w ten sposób i posługiwać się starym laptopem. Chcę aby to wreszcie działało na nowym jak należy. Dlatego dzisiaj odinstalowałem wszystko. Subiekta, ssms, i sql server 2008 r2 wyczyściłem wszystko i odnowa instalacja po kolei.
1 sql server 2008 r2
2 utworzyłem bazę INSERTGT
3 pełna instalacja Subiekt GT
4 Dearchiwizacja do podmiotu w programie Archiwizator
5 Po uruchomieniu Subiekta wybrałem utworzony podmiot a następnie aktualizacja bazy.
aktualizacja przebiega a na koniec wywala w/w błąd.
było pytanie jak robiłem kompaktowanie.
Program serwisowy, następnie zaznaczam podmiot i wybieram kompaktowanie.
W ten sposób przebiegło pomyślnie.
-
Czyli jest problem czy go nie ma ???
Są/bywają pewne problemy przy logowaniu w wersji 1.45 ...
-
Czyli jest problem czy go nie ma ???
Jakiś jest, ale wymaga diagnozy w miejscu występowania, a nie przez forum.
Są/bywają pewne problemy przy logowaniu w wersji 1.45 ...
Nie nazwałbym tego problemem i wszystko zostało wyjaśnione w wątku temu poświęconemu.
-
....
1 sql server 2008 r2
2 utworzyłem bazę INSERTGT
3 pełna instalacja Subiekt GT
4 Dearchiwizacja do podmiotu w programie Archiwizator
5 Po uruchomieniu Subiekta wybrałem utworzony podmiot a następnie aktualizacja bazy.
aktualizacja przebiega a na koniec wywala w/w błąd.
A co daje pkt 2? Bo nie spotkałem się z takim postępowaniem. Po prostu do pustego sql dearchiwizuje się podmiot, podając tylko nazwę bazy, którą sam utworzy.
Oprócz tego SQLl 2008R2 może mieć problemy na Win 10. Zalecany jest SQL 2014, który jest udostępniny przez Insert.
Z ostatnich informacji wynika, że pełna instalka zawiera oba serwery i jest domyslnie instalowany ten, który bardziej pasuje do systemu.
-
Podejrzewam że w pkt 2 miało być o instancji INSERTGT, a nie o bazie INSERTGT ;)
-
Przepraszam miała być instancja a nie baza w punkcie 2.
Dziękuję za trop odnośnie wersji sql. W poniedziałek wywalę wersję 2008 i zainstaluje 2014. Sugerowałem się tym co jest do ściągnięcia na stronie subiekta.
-
SQL 2008 R2 SP1 może mieć problemy bo nie jest oficjalnie wspierany, ale jak na razie o takich problemach nie słyszałem.
-
Sam używam 2008R2 na W10 i na żadne problemy się nie natknąłem.
-
A jak masz zrobione uwierzytelnianie do baz InsERTa? Windows, po koncie serwera MS SQL (sa), czy mieszanie? Sprawdź czy wszędzie masz po sa (wyłącz uwierzytelnianie po Windows i mieszane na serwerze) i czy operacje aktualizacji wykonujesz na 100% maszynie gdzie jest zainstalowany serwer MS SQL z bazą InsERTa. Mnie to wygląda na problemy z uprawnieniami na MS SQL. I na wszelki wypadek może nie aktualizuj bazy z Subiekta, tylko zaloguj się do Programu Serwisowego po koncie sa i spróbuj aktualizację bazy zrobić programem serwisowym a nie z Subiekta.
-
A jak masz zrobione uwierzytelnianie do baz InsERTa? Windows, po koncie serwera MS SQL (sa), czy mieszanie? Sprawdź czy wszędzie masz po sa (wyłącz uwierzytelnianie po Windows i mieszane na serwerze)
Nie jestem pewny co masz na myśli, są tylko dwa możliwe ustawienia po stronie serwera SQL - autentykacja Windows i mieszana, nie da się wyłączyć autentykacji Windows.
-
Niestety problem niepokonany.
Zmieniłem wersję sql z 2008 na 2014
Próbuje również poprzez program serwisowy logując się na konto sa Nie udało się ale jest mały postęp, teraz komunikat o błędzie wygląda następująco.
Kompaktowanie podmiotu...Nie powiodło się:
Błąd 0x80004005: Nieokreślony błąd.
Aktualizacja podmiotu nie powiodła się: 0x80004005: Nieokreślony błąd.
Przywrócenie podmiotu powiodło się
Przy instalacji sql wybrałem autentykacja windows. Czy teraz mogę to zmienić czy muszę zrobić reinstall sqla??
-
Możesz to zrobić przy pomocy Management Studio. Trzeba doinstalować, chyba, że zainstalowałeś SQL w wersji standard.
-
Problem rozwiązany.
Pomogło NIE zaznaczenie autentykacji windows przy instalacji sqla
Dziękuję wszystkim za chęć pomocy. W szczególności koledze @Artwi
-
Czyli tak naprawdę nie wiadomo co pomogło.
-
Czyli tak naprawdę nie wiadomo co pomogło.
Raczej wiadomo. Zauważyłem, że przy "mieszanym" uwierzytelnianiu na MS-SQL bardzo często zdarza się, że coś jest tworzone przez niedopatrzenia w sofcie (np. pliki tymczasowe) lub wywoływane przez MS-SQL lub oprogramowanie z niego korzystające raz z uwierzytelnieniem po sa a raz jako użytkownik windows albo fragment softu utworzył plik z uwierzytelnieniem od sa a inny chce to odczytać jako użytkownik windows i potem nie ma dostępu do jakiś plików lub uprawnień bo mają drugi rodzaj uwierzytelnienia i wtedy wyskakuje taki błąd. Ponadto często nawet jak się jest użytkownikiem administratorem Windows i ma się uprawnienia administratora z uwagi na uwierzytelnienie po Windows na MS-SQL to często są one niższe niż wymagane sa, szczególnie przy logowaniu zdalnym. Dlatego najlepiej przy bardziej zaawansowanych rzeczach typu konwersja baz danych uwierzytelniać się po sa jak się nie chce mieć problemów.
-
Szczerze mówiąc nie wiem o czym mowa. Jakie pliki z uwierzytelnianiem? Jakie pliki tymczasowe?
Nie spotkałem się dotąd z takim problemem, a w świecie mrowie serwerów ma wyłączone uwierzytelnianie mieszane, korzysta tylko z Windows i żyje.
-
Szczerze mówiąc nie wiem o czym mowa. Jakie pliki z uwierzytelnianiem? Jakie pliki tymczasowe?
Nie spotkałem się dotąd z takim problemem, a w świecie mrowie serwerów ma wyłączone uwierzytelnianie mieszane, korzysta tylko z Windows i żyje.
To mrowie serwerów z mieszanym uwierzytelnieniem żyje bo ma soft dobrze napisany a nie jak InsERT... InsERT dobrze działa z "każdym" uwierzytelnieniem pod warunkiem, że to "każde" jest kontem sa lub innym na MS-SQL o bardzo wypasionych uprawnieniach a nie na uwierzytelnieniu Windows... Krótka kwerenda po google na temat błędu 0x80004005 przy MS SQL zwraca info, że zwykle jest to problem z dostępem do pliku tymczasowego (uprawnienia). Dalsze poszukiwanie w google i dostajemy info, że zwykle takie problemy pojawiają się gdy do takiego pliku usiłują się dostać procesy odpalone przez różnych użytkowników. Ponieważ Insert jest domyślnie skonfigurowany z uwierzytelnieniem po koncie na MS-SQL (i to 'sa' niestety i nawet mam mailowe, nieprawdziwe zresztą, zapewnienie pomocy technicznej InsERTa, że nie da się skonfigurować InsERTA GT z uwierzytelnieniem innym niż konto sa na MS-SQL...) i gdy na serwerze MS-SQL jest włączone wyłącznie uwierzytelnienie po Windows, to zapewne InsERT przy aktualizacji wali plikami, których właścicielem jest konto na MS-SQL a odczytać usiłuje użytkownik Windows lub odwrotnie. Jestem tego pewien na 99%, stąd włączenie uwierzytelniania po kontach na MS-SQL (a przypominam, że taka jest domyślna w InsERT GT) rozwiązuje problem.
-
Szczerze mówiąc nie wiem o czym mowa. Jakie pliki z uwierzytelnianiem? Jakie pliki tymczasowe?
Nie spotkałem się dotąd z takim problemem, a w świecie mrowie serwerów ma wyłączone uwierzytelnianie mieszane, korzysta tylko z Windows i żyje.
To mrowie serwerów z mieszanym uwierzytelnieniem żyje bo ma soft dobrze napisany a nie jak InsERT... InsERT dobrze działa z "każdym" uwierzytelnieniem pod warunkiem, że to "każde" jest kontem sa lub innym na MS-SQL o bardzo wypasionych uprawnieniach a nie na uwierzytelnieniu Windows...
Przestań pisać takie bzdury i nieprawdę, o mapowaniu użytkownika Windows na użytkownika SQL, a tym samym uprawnieniach w systemie operacyjnym Windows i serwerze SQL nie decyduje oprogramowanie tylko administrator serwera SQL, jeśli uprawnienia zostaną nadane poprawnie to programy Insertu i wszystkie inne też będą działały poprawnie.
Krótka kwerenda po google na temat błędu 0x80004005 przy MS SQL zwraca info, że zwykle jest to problem z dostępem do pliku tymczasowego (uprawnienia). Dalsze poszukiwanie w google i dostajemy info, że zwykle takie problemy pojawiają się gdy do takiego pliku usiłują się dostać procesy odpalone przez różnych użytkowników. Ponieważ Insert jest domyślnie skonfigurowany z uwierzytelnieniem po koncie na MS-SQL (i to 'sa' niestety i nawet mam mailowe, nieprawdziwe zresztą, zapewnienie pomocy technicznej InsERTa, że nie da się skonfigurować InsERTA GT z uwierzytelnieniem innym niż konto sa na MS-SQL...)
Już wielokrotnie, również na tym forum słyszeliśmy, że pomoc techniczna pozostawia wiele do życzenia i często proponuje bezsensowne rozwiązania oraz wprowadza w błąd, więc kolejna bzdura to nic nowego, dziwi mnie tylko ufność wobec pomocy, zwłaszcza przy odpowiedziach typu "nie da się" lub braku rozwiązania problemu.
i gdy na serwerze MS-SQL jest włączone wyłącznie uwierzytelnienie po Windows,
Już zwracałem na to uwagę, a Ty dalej swoje - nie ma żadnego "gdy", przecież autentykacja Windows na serwerze SQL jest dostępna "zawsze", nie da się jej wyłączyć.
, to zapewne InsERT przy aktualizacji wali plikami, których właścicielem jest konto na MS-SQL a odczytać usiłuje użytkownik Windows lub odwrotnie. Jestem tego pewien na 99%, stąd włączenie uwierzytelniania po kontach na MS-SQL (a przypominam, że taka jest domyślna w InsERT GT) rozwiązuje problem.
Wypadałoby się dowiedzieć o podstawach działania serwera SQL oraz na czym polega konwersja bazy danych zanim będzie się deklarowało 99% pewności... Przy autentykacji Windows serwer SQL wykonuje operacje w systemie operacyjnym z uprawnieniami zalogowanego użytkownika, a nie konta usługi serwera SQL... Programy Insertu nie tworzą bezpośrednio żadnych plików (poza logiem z konwersji), wszystkie pliki, a są to pliki baz danych są tworzone przez serwer SQL.
-
Trzeba dodać, że uwierzytelnienie Windows sprawdza się, gdy jest sieć domenowa i każdy użytkownik jest zdefiniowany jako członek domeny.
Przy komputerach podpiętych do luźnej sieci (bez domeny) logowanie Windows ma sens tylko na serwerze, natomiast nie ma na końcówkach, gdzie na każdym komputerze są zdefiniowani inni użytkownicy.
Podstawowe uwierzytelnienie SQL przyjęte przez Insert (na sa) jest takim, które zadziała w dowolnej sieci i nie wymaga ingerencji w ustawienia serwera SQL.
A jak ktoś chce się zabezpieczyć, to jego wola i tylko sprawa wiedzy i umiejętności, żeby to zrobić.
-
Przestań pisać takie bzdury i nieprawdę (...)
Dziękuję, nie chciało mi się już dalej wojować, a zostawić tego tak też nie bardzo wypadało.
-
@ dkozlowski
Drogi Kolego. Zwykle każda mamusia uważa swoje dziecko za niewinne, więc i Kolega może uważa InsERTa za najdoskonalszy produkt od czasu wynalezienia koła i za problemy wini wszystko (a najchętniej administratora) a nie program. Proszę jednak o trochę obiektywizmu. Zawsze, gdy tylko jakiś program teoretycznie da się uruchomić na jakimś komputerze (a InsERTa da się), to można wzorem Kolegi wszystkie problemy z działaniem zgonić na administratora i teoretycznie, ale tylko teoretycznie, będzie to prawda, bo administrator ma teoretycznie możliwość wszystkie problemy usunąć. Jednak ODROBINA przyzwoitość wymaga, by jednak program lub jego instrukcja przynajmniej trochę temu administratorowi w tym pomogły. Spójrzmy jak sprawa wygląda:
- Kolega się z pewnością zgodzi, że zalecaną przez Microsoft konfiguracją MS SQL jest uwierzytelnianie po Windows, prawda?
- Kolega się z pewnością zgodzi, że InsERT poszedł po najmniejszej linii oporu i instaluje się z uwierzytelnianiem po koncie na MS SQL i to w dodatku 'sa', prawda?
- Kolega się z pewnością zgodzi, że brak zgodności metod uwierzytelniania może prowadzić do problemów i chyba nie jest to niespotykane, skoro od wersji 1.44 są już 2 wątki na ten temat, prawda?
- Nie wiem jak teraz, ale przynajmniej przed rokiem, kiedy ostatni raz czytałem, instrukcja InsERTa ani nie ostrzegała, ani program tego nie sprawdza, przed problemami z mieszanym sposobem uwierzytelnienia i poprzestaje na suchym "0x80004005: Nieokreślony błąd." (choć jak wspomniałem w Google można łatwo znaleźć skąd się taki błąd zwykle bierze), a takie ostrzeżenie powinno być, prawda?
- Oczywiście jak Kolega można o wszystko winić administratora, który przecież powinien być wszechwiedzący, a nie "doskonały"program, więc ten administrator pewnie, a nie program, powinien wiedzieć skąd bierze się "nieokreślony" błąd 0x80004005, jednak w praktyce nie ma doskonałych administratorów i Kolega przyzna, że nie tylko początkujący Kolega tomson5 nie wiedział jak rozwiązać problem, ale też nie wiedział ekspert Aldo ani ekspert candy ani sam guru dkozlowski...
- Nie winię za to wspomnianych Kolegów ekspertów (sam to wiem przypadkowo, bo rok temu miałem podobny problem i nie na InsERT), tylko winię za to twórców InsERTa: gdyby program stosował uwierzytelnienie zalecane przez Microsoft, albo podawał w instrukcji jak mapować uprawnienia na MS SQL (nie każdy jest takim ekspertem jak Kolega by to wiedział), albo choć ostrzegał przed problemem czy to w instrukcji czy to komunikatem programu (zamiast "wiele mówiącegu" 0x80004005: Nieokreślony błąd.) to taki błąd by się albo nie zdarzał, albo Koledzy eksperci wiedzieliby jak go rozwiązać.
Przy autentykacji Windows serwer SQL wykonuje operacje w systemie operacyjnym z uprawnieniami zalogowanego użytkownika, a nie konta usługi serwera SQL... Programy Insertu nie tworzą bezpośrednio żadnych plików (poza logiem z konwersji), wszystkie pliki, a są to pliki baz danych są tworzone przez serwer SQL.
- skoro Kolega tak twierdzi, to pewnie tak jest, tylko dlaczego bez włączenia uwierzytelniania po koncie MS SQL konwersja nie działa?... (oczywiście przyczyn może być wiele, np. brak uprawnień tego użytkownika Windows do plików na tym serwerze baz danych, ale instrukcja InsERT nie podaje jakie uprawnienia powinien mieć, prawda? I Kolega gwarantuje, że InsERT, zainstalowany domyślnie po koncie z MS SQL, nie wywołuje części procedur na MS SQL po koncie na MS SQL a części z uwierzytelnieniem Windows jak takowe się stosuje?)
Wobec powyższego, Kolego dkozlowski, pozwolę sobie pozostać przy zdaniu, że winnym przedmiotowego problemu jest InsERT a nie niekompetencja administratora (czy tym bardziej użytkowników) i zamiast krytykować użytkowników, lepiej by Insert uderzył się w piersi i poprawił jeśli już nie program, to instrukcję i przynajmniej uczulił użytkowników na błędy i ich objawy z mieszania sposobów uwierzytelnienia a najlepiej jakby jeszcze opisał wspomniane przez Kolegę mapowanie uprawnień na serwerze MS-SQL. Przyznaję bez bicia, że od roku tej instrukcji nie czytałem, więc nie mam 100% pewności że tego nie ma, ale mniemam, że gdyby było, to taki ekspert jak Kolega potrafiłby podać rozwiązanie wspomnianego błędu.
-
Dobrze że to nie do mnie ;)
Mnie już ręce opadły od tego pomieszania wszystkiego że wszystkim.
-
Nie chce mi się odpowiadać na wszystko (bo może mi się nie chcieć :) ).
Ciekaw jestem tylko ile byłoby krzyku od użytkowników, którzy przy mieliby pozostawione tylko logowanie Windows (zalecane), nie mieliby serwera (domeny itd) i chcieliby pracować na kilku komputerach.
Już teraz widzimy jakie są problemy jak ktoś uważa, że podczas własnoręcznej instalacji serwera SQL wystarczy tylko klikać "next, next" i ma własnie autoryzację Windows. I wtedy jest krzyk, że na"serwerze" działa a na końcówkach nie działa i dlaczego?.
I to nie jest LINIA NAJMNIEJSZEGO OPORU (taka jest poprawna forma), ale bardzo zdrowe podejście. Zauważ, że nawet celowo jest usuwane hasło na "sa", żeby początkujący użytkownik sobie poradził.
Jeżeli ktoś ma już serwer, to albo potrafi sam albo ma kogoś kto ustawi mu logowanie Windows.
-
Nie chce mi się odpowiadać na wszystko (bo może mi się nie chcieć :) ).
Ciekaw jestem tylko ile byłoby krzyku od użytkowników, którzy przy mieliby pozostawione tylko logowanie Windows (zalecane), nie mieliby serwera (domeny itd) i chcieliby pracować na kilku komputerach.
Już teraz widzimy jakie są problemy jak ktoś uważa, że podczas własnoręcznej instalacji serwera SQL wystarczy tylko klikać "next, next" i ma własnie autoryzację Windows. I wtedy jest krzyk, że na"serwerze" działa a na końcówkach nie działa i dlaczego?.
I to nie jest LINIA NAJMNIEJSZEGO OPORU (taka jest poprawna forma), ale bardzo zdrowe podejście. Zauważ, że nawet celowo jest usuwane hasło na "sa", żeby początkujący użytkownik sobie poradził.
Jeżeli ktoś ma już serwer, to albo potrafi sam albo ma kogoś kto ustawi mu logowanie Windows.
Częściowo z Kolegą się zgodzę. Mogę zgodzić się co do domyślnej konfiguracji, ale nie mogę zgodzić się co do braku ostrzeżeń w tej sprawie, nawet w instrukcji. Np. w żenującym Płatniku też jest instalacja po sa (ale też jest po Windows, nawet zalecana), lecz już w podręczniku administratora zalecają zmianę konta i podają jego uprawnienia (nie w sposób doskonały - nie da się na tym koncie utworzyć np. nowej bazy w celu eksportu i o tym już instrukcja nie wspomina). W InsERT o tym cisza, czego efektem jest, że nawet Koledzy eksperci potem nie wiedzą skąd się bierze problem (dlatego nie zgadzam się z ostatnim zdaniem wypowiedzi Kolegi). Co gorsza, zamiast przyznać (jak Kolega) że problem jest, to idą w zaparte lub co gorsza bawią się w "wojowników forumowych" ("nie chciało mi się już dalej wojować"...) i atakują tego, który rozwiązanie wskazał. Z prostej sprawy: jest błąd, jest znana przyczyna - trzeba poprawić (może nawet podziękować za wskazanie problemu, ale nawet nie śmiem o tym marzyć...) jest wyparcie i "wojowanie forumowe". Nie pierwszy zresztą raz, bo podobnie było jak wskazałem sprawę zmiany uprawnień do pliku Subiekt.xml na serwerze terminali po aktualizacji InsERTa- też zamiast przyznać że jest problem (i nawet podałem sposób rozwiązania) to znowu mamy "InsERT niewinny" i "nic nie zmieniał" tylko jakoś u wielu osób nikt nie będący administratorem po aktualizacji nie miał dostępu do tego pliku. Nie domagam się od InsERTa doskonałości ani od forumowych ekspertów wszechwiedzy ale oczekuję, że jak jest błąd i to najwyraźniej ze strony InsERTa, to metodą powinna być akceptacja jego istnienia i stworzenie jego rozwiązania a nie wypieranie się winy i atakowanie zarzutami nieuctwa tych, którzy go wskazali. Nawet gdyby się zgodzić, że to nie błąd InsERTa, to trzeba się zgodzić, że to problem dotyczący InsERTa, więc powinno być o tym wspomniane jeśli nie w komunikacie programu, to w instrukcji (z opisem jak ustawić uprawnienia uwierzytelniania po Windows) bo bez tego jak widać i forumowi eksperci mają kłopoty.
-
Kolega się z pewnością zgodzi, że zalecaną przez Microsoft konfiguracją MS SQL jest uwierzytelnianie po Windows, prawda?
I co z tego?
Ważny jest powód, a tym są względy bezpieczeństwa, a nie problemy z konwersją bazy, dostępnością plików tymczasowych (jakich plików tymczasowych to nie dowiedzieliśmy się pory).
Za technet.imcrosoft.com: "Security note. When possible, use Windows Authentication."
Kolega się z pewnością zgodzi, że brak zgodności metod uwierzytelniania może prowadzić do problemów
Najpierw musi być jakakolwiek niezgodność, a tego na razie nie wiemy. Ba! Nie wiemy nawet co z czym miałby być niezgodne.
-
Subiekt GT znam i instaluję/wdrażam/naprawiam od wersji 1.00. W swoim długim już (ponad 20 letnim) stażu pracu wielokrotnie instalowałem oprogramowanie korzystające z architektury klient-serwer, zarówno MSSQL jak i Firebird czy Oracle. W MSSQL wielokrotnie instalowałem/aktualizowałem przeróżne programy, zaczynając od Insertu, poprzez programy WA-PRO i Comarchu. I kolego Artwi informuję Cię, że wszystkie instalują się domyślnie z autentykacją mieszaną (po loginie użytkownika silnika bazodanowego). Dodam też (bo o tym wątek), że to nie powoduje problemów z konwersją/dostępnością do plików.
Jakby była potrzeba udokumentowania mojej wiedzy dyplomami, to mogę ewentualnie zeskanować :)
-
Myślę, że trzeźwo myślący admin zdaje sobie sprawę z tego, że Microsoft zaleca stosowanie autentykacji Windows z pewnych, ściśle określonych względów. Widać to nawet przy instalowaniu windowsa w wersji pro, gdzie po drodze jest pytanie o domenę i trzeba się doszukać możliwości wyłączenia tego. W wersji home tego nie ma.
Dla Microsoftu, przy jego korporacyjnym myśleniu w firmach sieci powinny być tylko i wyłącznie domenowe i pod to są robione rozwiązania.
Natomiast życie, jak zwykle, generuje swoje przypadki i małe firmy ze względu chociażby na koszty nie pójdą w sieci domenowe.
I dlatego też Insert (i nie tylko) zastosował takie, a nie inne rozwiązanie, bo dopasował się do naszych realiów. I to działa.
Natomiast jak pewne rzeczy robi się ręcznie, to trzeba wiedzieć co i jak się robi, a nie oczekiwać do wszystkiego komunikatów.
Instalując ręcznie serwer sql domyślną autentykacją jest windowsowa, ale wybierając mieszaną trzeba obowiązkowo podać hasło do sa. No i później są schody z logowaniem, bo wielu instalujących "coś tam" wpisze, a później okazuje się, że nie działa. I przy takim podejściu tak ma być. Albo wiesz co robisz, albo się za to nie bierz.
-
U mnie taki problem spowodowała zmiana ustawienia Region, Format na angielski (prawdopodobnie zmienił to jakiś program przy instalacji).
Powrót do polskiego rozwiązał błąd aktualizacji parametrów historycznych.
Dziękuję za znalezienie rozwiązania Pomocy Technicznej Insert.