Zmiany w Somedzie.

[Brutus69]

 Witam. 
Odważyłem się dzisiaj na  zainstalowanie  aktualizacji i oczywiście nie obyło się bez problemów ?  ... "wpisy w rejestrze są uszkodzone"...   W ks konfiguratorze próbowałem wpisać poprawne hasło dla użytkownika gabinet ale nic to nie dało ?  komunikat  błędne hasło...   Wykonałem 3 czynności i mówiąc szczerze nie wiem która okazała się kluczowa ?  wyczyszczenie wartości xpas w rejestrze, przywrócenie domyślnego hasła użytkownika gabinet, oraz usunięcie pliku kspl.ini (Dzięki Neelix ).   Program ruszył, faktycznie po prawidłowym skonfigurowaniu stanowiska z którego pobierane są aktualizacje pozostałe stanowiska  zaktualizowały się bez problemu ? łączą się z bazą i wszystko wydaje się działać prawidłowo.   Zalogowałem się zdalnie do 5 komputerów i na wszystkich program działał w miarę stabilnie, jakkolwiek mam wrażenie że nieco dłużej trwało zamykanie modułu lekarskiego. Sprawdziłem ustawienia ról  użytkowników ? nie zauważyłem  żadnych zmian w ustawieniach uprawnień poszczególnych użytkowników czy ról. Pracuję na żywym  organizmie ? aktualizację wykonałem zdalnie po pracy jutro ruszamy już w nowej rzeczywistości ? pracujemy na 10 stanowiskach z czego 3 łączą się przez server terminali,  jeśli zauważę jakieś dziwne zachowania programu dam znać. Pozdrawiam

[Brutus69]

Jednak na końcówkach musiałem wyczyścić wartość xpass w rejestrze (możliwe ze powodem było zrestartowanie hasła ) inaczej nie chciały połączyć się z serwerem.

[Sorn]

Nic mi nie wiadomo, aby uprawnienia i role się zmieniły. Co więcej nie mają prawa, bo one nie są uzależnione od stanowiska, a od operatora. A tu NIC nie zostało zmienione.

Czyli mam rozumieć, że poniższy tekst dla modułu Administrator w raporcie zmian został dodany przez pomyłkę:
1. Zmieniono mechanizm działania ról w uprawnieniach. Obecnie role mogą być ukrywane (ukrycie roli oznacza
odjęcie uprawnień, które dawała rola).
W przeciwieństwie do rozwiązania funkcjonującego do tej pory, nowe
role nie posiadają żadnych domyślnych uprawnień. Funkcjonujące do tej pory uprawnienia domyślne zostały
usunięte ze wszystkich ról i przeniesione do nowo utworzonej roli o nazwie UŻYTKOWNIK STANDARDOWY, do
której zostają przypisani wszyscy pracownicy.
Prosimy o zweryfikowanie poprawności przypisania uprawnień.

[Brutus69]

 Po pierwszym dniu pracy:
1.  System działa stabilnie i wydaje mi się że szybciej niż przed aktualizacją.  Wszystko drukuje się i skanuje bez problemu.
2.  Dotychczasowe ustawienia uprawnień poszczególnych użytkowników i ról zostały zachowane i działają prawidłowo
3.   Numery stanowisk w przypadku połączenia przez Server terminali pomieszały się całkowicie, trzeba było je ręcznie zmieniać  zgodnie z opisem do aktualizacji, , jakkolwiek nie obyło się bez problemów,  nie jest to rozwiązanie intuicyjne,  kilka komunikatów na czerwonym tle nieco utrudniło sprawę  ale jest to do zrobienia.   W przypadku połączeń nie przez Server terminali numery stanowisk zostały zachowane.
4.  Jest problem w przypadku próby zabicia sesji bazy danych z modułu Serwis ? niefortunnie na dwóch  stanowiskach zawiesiłaby się dwie sesje  co skutkowało komunikatem o niemożności połączenia gdyż dane stanowisko jest już połączone z bazą danych.  Oczywiście poprzednio zdefiniowany użytkownik do zabijania sesji zniknął, stworzylem nowego użytkownika gmadm (taki jak w kskonfiguratorze) i nadalem mu uprawnienia  zgodnie z opisem na stronie 4 instrukcji obsługi  moduł Serwis .  Użytkownik został stworzony poprawnie, uprawnienia zostały nadane prawidłowo, mogę się na użytkownika zalogować przez sql plusa,  natomiast w  KS konfiguratorze nie mogę się zalogować ? pojawia się komunikat na czerwonym tle o błędnym haśle...   Nie można więc póki co zabić sesji z modułu Serwis, jeżeli komuś udało się ten problem rozwiązać będę Wdzięczny za informację.   Póki co napisałem zapytanie do pomocy Kamsoftu i czekam...
Pozdrawiam

[neelix]

4.  Jest problem w przypadku próby zabicia sesji bazy danych z modułu Serwis ? niefortunnie na dwóch  stanowiskach zawiesiłaby się dwie sesje  co skutkowało komunikatem o niemożności połączenia gdyż dane stanowisko jest już połączone z bazą danych.  Oczywiście poprzednio zdefiniowany użytkownik do zabijania sesji zniknął, stworzylem nowego użytkownika gmadm (taki jak w kskonfiguratorze) i nadalem mu uprawnienia  zgodnie z opisem na stronie 4 instrukcji obsługi  moduł Serwis .  Użytkownik został stworzony poprawnie, uprawnienia zostały nadane prawidłowo, mogę się na użytkownika zalogować przez sql plusa,  natomiast w  KS konfiguratorze nie mogę się zalogować ? pojawia się komunikat na czerwonym tle o błędnym haśle...   Nie można więc póki co zabić sesji z modułu Serwis, jeżeli komuś udało się ten problem rozwiązać będę Wdzięczny za informację.   Póki co napisałem zapytanie do pomocy Kamsoftu i czekam...
Pozdrawiam

Z tym też mam problem, wydaje mi się że to ta sam sytuacja co przy konfiguracji połączenia dla użytkownika gabinet - mimo że w polu nazwa użytkownika widać wpisane "gabinet" to po podaniu hasła nie można było testowo zalogować się do bazy, po wpisaniu hasła i kliknięciu OK można edytować to pole i po wpisaniu tej samej nazwy "gabinet" i hasła już się łączy. Ale z polem do admina bazy już ta sztuczka nie udaje się, na dwóch instalacjach nie mogę tego edytować. Chyba czas zajrzeć do instrukcji.

[MK]

Żeby była jasność. Pierwsze okienko służy do weryfikacji. Podajemy tu hasło, aby pozwolić w następnym okienku na zmianę tego hasła. Jest to zabezpieczenie przed przypadkowym uszkodzeniem hasła przez osobę niezorientowaną. Na tym etapie nie testujemy jednak hasła w bazie a sprawdzamy je z zapisanym w pliku ini lub w rejestrach. Jeśli więc mieliśmy zamieszanie z licencją może być tak, że hasło w rejestrach zakodowane było innym kluczem niż też wpisujemy. Stąd np. komunikat o niepoprawnym haśle. Który wcale nie sugeruje, że hasło  bazie jest inne! Jeśli tak mamy, najlepiej usunąć wpis z rejestrów i z pliku ini z użytkownikiem i hasłem i wpisać je od nowa. Wówczas na początek należy wpisać hasło GM, które znów nie musi odpowiadać rzeczywistości, program je po prostu wymaga na starcie.
Później pojawia się drugie okienko i tu już należy wskazać użytkownika i hasło takie, jakie mamy w bazie.
To samo dotyczy hasła systemowego. I znów jeśli są problemy należy hasła wyciąć i wpisać od nowa i z rejestrów i z pliku ini. I wówczas na starcie mamy użytkownika SYSDBA i hasło masterkey, które oczywiście nie musi odpowiadać rzeczywistości. Należy je jednak wpisać i w drugim okienku wpisać właściwego użytkownika i hasło

[Brutus69]

Wyczyściłem nazwę xsys w rejestrze i zadziałało   Dzięki.  W życiu bym na to nie wpadł. Swoją drogą zawsze mnie zastanawiało jakim szyfrem program szyfruje hasła że sam nie potrafi go rozszyfrować, po zmianie hasła z domyślnego hasła GM  można było się zalogować do KS konfiguratora tylko dwa razy:  pierwszy i ostatni...  Potem pomagało tylko wyczyszczenie wartości Xpass w rejestrze i tylko na 1 raz.   A tu się okazało że mam zamieszanie  w licencji.  Ale ja nigdy nie dotykałem pliku licencyjnego w sensie nigdy go nawet nie  próbowałem edytować.    Czy jeśli teraz zmienię hasło domyślne dla użytkownika gabinet  to będę musiał go zmieniać na wszystkich końcówkach, czy wystarczy że zmieni go tylko na końcówce, z której pobierane są aktualizację?  Czy jest jakiś sposób na rozwiązanie problemu  "zamieszania w licencji"?

[MK]

Może nie do końca jasno się wyraziłem. Gdyby Pan namieszał w licencji, to w ogóle program by się nie uruchomił, tylko napisał, że licencja jest uszkodzona. Licencja jest cyfrowo podpisana - no nie jest to oficjalny podpis, ale nie o to nam chodzi - w każdym razie, tak jak w podpicie cyfrowym zmiana jednej literki w licencji teoretycznie powinna być wykryta jako modyfikacja. A że mógłby Pan zmienić np. liczbę stanowisk na naszą niekorzyść  - przed tym się broimy. Tak więc nie o takie mieszanie mi chodzi.
Mówiłem o mieszaniu z licencjami. Czyli - nie wiem jak Pan - ale sporo osób instalowało wersję nową do nowego katalogu nową instalką. Czyli w katalogu NIE było licencji. Program odczytując hasło z rejestru rozkodował je błędnym kluczem - zerową licencją - i zakodował raz jeszcze błędnym kluczem - znów zerową licencją - tym razem zapisując w pliku. Ta zapisane hasło już teraz jest błędne, bo błędnie było rozkodowane z rejestru. Jeśli teraz, po wszystkim, wgra Pan do katalogu właściwą licencję to błędne hasło dodatkowo będzie błędnie odczytane - bo już prawidłową Pańską licencją. Może już trochę jest jaśniej, chodziło mi o to, że operacje na haśle przy udziale różnych licencji - w tym również jej braku - powodują tego typu problemu. Bo numer licencji jest kluczem kodowania. Stąd pisałem, że przede wszystkim należy usunąć wpisy z pliku ini, bo one z pewnością są niepoprawne. Z rejestrów - powinno być ok, skoro były zakodowane poprawna licencją więc po wgraniu do katalogu poprawnej licencji ich rozkodowanie powinno się udać. Ale na wszelki wypadek mówiłem o usunięciu i z rejestrów wpisów, bo wówczas może Pan spokojnie, od nowa ponownie, na prawidłowej wersji licencji wpisać hasła.

[Brutus69]

Wpis xsysuser i zakodowany xpass w pliku ini pojawił się dopiero teraz - tz po wykasowaniu z rejestru wpisu xsysuser i odpaleniu KS konfiguratora. Wcześniej sprawdzałem i  wogóle nie było  wpisu xsysuser.
Jak pisałem problem z hasłem w moim przypadku jest od dawna - i tak np jakieś pół roku temu zmieniliśmy serwer w sensie nowy sprzęt i nowy Oracle po tym wgrałem licencje i po kilku dniach pracy zmieniłem hasło z domyślnego GM na inne ( juz oczywiście po wgraniu licencji) zmieniłem hasło na serwerze następnie zalogowałem sie do KS konfiguratora na wszystkich końcówkach i zmieniłem tam hasło. I był to ostatni raz kiedy mogłem otworzyć KS konfiguratora.    W przypadku jakiekolwiek zmiany i konieczności użycia KS konfiguratora podanie domyślnego hasła lub nowego hasła skutkowało komunikatem błędu.  Jedynym sposobem było wyzerowanie hasła w rejestrze. Obecną aktualizacje wgrałem do isniejącego folderu uaktualniając działający program - nie była to nowa instalacja.

[MK]

Trudno mi teraz to rozwiązać. W każdym razie, nowym konfiguratorem może Pan teraz sprawdzić jak to działa. Konfigurator się uruchamia, ale aby zmienić ponownie hasło, należy podać zapisane. Jeśli się uda - pojawi się okienko zmiany haseł. Może Pan je anulować, ale w ten sposób sprawdzi Pan,czy nowy konfigurator już dział poprawnie i czy da się nim hasłami manipulować.
teraz zresztą konfigurator służy tylko w zasadzie do kodowania haseł inne wpisy spokojnie zrobi Pan  notatnikiem.

[neelix]

To jakie hasło podać dla admina bazy aby móc zmienić nazwę i podać nowe hasło? Chodzi o bazę oracle, masterkey nie działa ale to pewnie tylko dla firebirda.

[09061303]

Spróbuj gm.

[neelix]

Spróbuj gm.

Nie wchodzi.
I po ostatniej aktualizacji popsuło mi numeracje stanowisk, końcówki ustawiają się na nowe, kolejne numery, nie mogę ich zmusić do pracy na starych. .ini jest do dupy:D

[09061303]

I po ostatniej aktualizacji popsuło mi numeracje stanowisk, końcówki ustawiają się na nowe, kolejne numery, nie mogę ich zmusić do pracy na starych. .ini jest do dupy:D

To z hasłem nie mam pomysłu.

Coraz bliżej święta, coraz bliżej święta....
Niezła jazda...

[neelix]

Jeśli ktoś będzie miał problem z numeracją stanowisk dla XP to mi pomogła ta aktualizacja systemu:
https://support.microsoft.com/pl-pl/hotfix/kbhotfix?kbnum=971165&kbln=en-us

Rozwiązanie autorstwa infolinii Kamsoft, dziękuję!