Testujemy już wersję 2015.03.1, wersję, która pożegnamy BDE. Dostępna będzie zarówno instalka dla wersji 2015.03.1 jak i aktualizacja o numerze 2015.03.0.04, po wgraniu której otrzymamy wersję 2015.03.1. Aktualizacja oraz instalka powinny pojawić się już niebawem. Na pewno przed świętami.
Ważna uwaga, ten jeden jedyny raz nie będzie aktualizacji różnicowej. Zmian w plikach bibliotek jest tak sporo, że aktualizacja różnicowa nie ma najmniejszego sensu, byłaby ona sporo większa, niż zwykła aktualizacja ZIP. Proszę wziąć to po uwagę podczas szukania i pobierania aktualizacji.
Aktualizacji oczywiście towarzyszyć będzie biuletyn. I oczywiście będą w nim opisane wszelkie nowości. Ale nim ta wersja i biuletyn trafią do użytkowników, z kilkoma, mam nadzieję ciekawymi informacjami chciałbym się podzielić. Tym bardziej, że z racji nieoficjalności tej strony, można napisać czasem to, czego w oficjalnych informacjach raczej nie zamieścimy.
Porzucamy rejestry! Tak, ta wersja nie będzie już korzystała z rejestrów systemowych (no, może jeszcze nie do końca, bo jak na razie biblioteka do drukarki fiskalnej rejestry będzie wykorzystać, no i jeśli czegoś nie da się po nowemu odczytać, odczytamy z rejestrów). Dlaczego tak, chyba nie trzeba tłumaczyć. Nowe systemy powodują, że nawet my, twórcy KS-SOMED, mamy problem ze zlokalizowaniem gdzie też te skubane wpisy się znajdują. A mogą się pojawić w local_machine, czasem w current_user, jak ktoś ma 64bitowy system to jeszcze trzeba brać pod uwagę, że jest coś takiego jak wow6432node, no a jak ktoś ma ewidentnie pecha, to mu się wpisy zwirtualizują. Połapać się w tym już nie sposób. Dlatego też zapominamy o rejestrach. Jeszcze będziemy je czytać, ale już nie wymagamy ich. A za niedługo w ogóle o nich zapomnimy. Do tego czasu będzie potrzeba przenieś informację w inne miejsce.
Rejestrów już nie ma, co w zamian. Najśmieszniejsze jest to, że wracamy do przeszłości. To znaczy zamiast rejestrów używamy starego, sprawdzonego pliku ini. Co nam to daje? Wbrew pozorom bardzo dużo. Po pierwsze w jednym pliku będziemy mieli ustawienia dostępu do bazy danych jak i pozostałe ustawienia systemu, w szczególności ścieżka, z której poszczególne końcówki pobierać będą pliki. Po drugie, od razu wiadomo, gdzie szukać ustawienia. Wchodzimy do katalogu KS-SOMED, otwieramy tekstowy plik kspl.ini i mamy wszystko jak na dłoni. Po trzecie, cóż, myślę, że jeśli dział IT danej przychodni będzie zmuszony instalować nową końcówkę, lub w ogóle będzie instalował system KS-SOMED na nowo, to będzie za nas toasty wznosił Emotikon wink. Dzięki temu, że mamy plik ini, dzięki temu, że plik ten może być wspólny dla każdej końcówki (tak, może być, dlaczego?. niebawem), wystarczy aby na serwerze dokonać odpowiednich w nim zmian i każda końcówka przy swoim uruchamianiu pociągnie owe zmiany i uruchomi się z nową konfiguracją. Niby fajne, ale to przecież nie jest aż tak bardzo przydatne. W końcu jak często konfiguracja jest zmieniana. Ciekawsze jest jednak coś innego. KSPL.EXE potrafi pobrać z serwera biblioteki, ale też inne pliki. Między innymi plik ini. Plik ten zastąpi wówczas plik ini znajdujący się na końcówce. Jeśli teraz to wszystko ze sobą połączymy, a więc brak rejestrów, cała konfiguracja w pliku ini, łącznie z konfiguracją połączenia do bazy danych, kspl.exe, który potrafi pobrać inne pliki, to wychodzi nam, że aby na nowej końcówce zainstalować KS-SOMED wystarczy utworzyć katalog, umieścić w nim trzy pliki (kspl.exe wystarczy, by był z wersji 2015.03.1.00, borlandmm.dll, oraz kspl.ini z jednym jedynym wpisem informującym o lokalizacji katalogu, z którego można pobrać aktualne biblioteki systemu KS-SOMED), uruchomić kspl.exe i zaparzyć sobie kawę. Jak wrócimy, powinniśmy w katalogu odnaleźć pełen system KS-SOMED z aktualnym plikiem kspl.exe (sam się potrafi zaktualizować do najnowszej wersji) oraz z aktualnym plikiem kspl.ini zawierającym informację o wszystkich potrzebnych informacjach w tym o połączeniu z baza danych. Słowem w pełni działający system KS-SOMED. O ile wcześniej zainstalowaliśmy też klienta bazy danych. Choć, nieoficjalnie, i z tym można sobie poradzić. Jeśli na serwerze w podkatalogu dbClient umieścimy klienta bazy danych w wersji instance (dla Oracle) lub gds32.dll dla firebirda, to mamy szansę, że bez instalacji klienta KS-SOMED połączy się z bazą danych. Katalog ten bowiem również zostanie na końcówkę skopiowany, a podczas uruchamiania dowolnego programu wchodzącego w skład systemu KS-SOMED katalog ten zostanie dodany do lokalnej wersji zmiennej środowiskowej PATH. Co powinno zapewnić, że klient zostanie odnaleziony i załadowany przez program. Te jednak rozwiązanie, bez instalacji klienta, jest rozwiązaniem nieoficjalnym. Do wykorzystania na własne ryzyko.
Cóż, nigdy nie ma dobrego czasu na takie zmiany...A jak będzie ze zwolnieniami lekarskimi, będą w somedzie czy tylko przez ZUS ?
u mnie nastąpił dramatyczny spadek wydajności, praktycznie uniemożliwiający pracę. Zwiechy systemu, makabra - na szczęście robiłem na serwerze testowym. Coś nie tak....Z tego co wiem, były z tym problemy ok roku temu i dlatego opóźniane było wejście w życie. Myślałem, że temu już poradzili. A po aktualizacji odwrotu nie ma raczej (tego nie wiem, ale sugerowanie kasowania wszystkich plików i brak kopii różnicowych nie za kolorowo wygląda).
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ę:
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...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.
Pozdrawiam
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:DTo z hasłem nie mam pomysłu.
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.
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.
Hasło: GM (koniecznie dużymi)
Poszło "masterkey" jak usunąłem xsyspass z pliku ini.Czyli baza firebird :)
Poszło "masterkey" jak usunąłem xsyspass z pliku ini.Czyli baza firebird :)
A nie bo oracle :DMnie zadziałało GM. Zakładam, więc że dwa loginy i hasła są na sztywno zapisane w konfiguratorze bez względu jaką bazę się wybierze :)
Jest tak jak pisze MK: SYSDBA i masterkey są ustawione "na sztywno" i to są hasła potrzebne do zmiany usera i hasła do bazy. Po ich podaniu dopiero można wprowadzić nazwę usera bazy służącego do zabijania sesji, stworzonego zgodnie z instrukcją do modułu serwis i odpowiednie do niego hasło.
Wcześniej "masterkey" mi nie działał bo był wpis xsyspass w pliku ini.
A nie bo oracle :DMnie zadziałało GM. Zakładam, więc że dwa loginy i hasła są na sztywno zapisane w konfiguratorze bez względu jaką bazę się wybierze :)
Jest tak jak pisze MK: SYSDBA i masterkey są ustawione "na sztywno" i to są hasła potrzebne do zmiany usera i hasła do bazy. Po ich podaniu dopiero można wprowadzić nazwę usera bazy służącego do zabijania sesji, stworzonego zgodnie z instrukcją do modułu serwis i odpowiednie do niego hasło.
Wcześniej "masterkey" mi nie działał bo był wpis xsyspass w pliku ini.
Dobrze wiedzieć ;)
Tak przy okacji, czy ktoś już stawiał Somed na Oracle 12?
Zmieniła się architektura w 12 i nie można używać zmiennych $ dla widoków w bazie a jak wiadomo jeden z nich w Somedzie ma nazwę "v$s". Coś z tym fantem KS zaradził, czy jeszcze nie używamy v. 12 ?
No właśnie, podejrzewam że to w związku z tym nieszczęsnym widokiem w ks-somed. Możesz coś więcej napisać? Pewnie jakiś alter, który zmienia nazwę widoku i odwołania innych obiektów do zmienionej nazwy....
Tak przy okacji, czy ktoś już stawiał Somed na Oracle 12?
Zmieniła się architektura w 12 i nie można używać zmiennych $ dla widoków w bazie a jak wiadomo jeden z nich w Somedzie ma nazwę "v$s". Coś z tym fantem KS zaradził, czy jeszcze nie używamy v. 12 ?
Ja używam na 12 (u jednego klienta od 2 lat). Ale są problemy z integracją. Przy każdej aktualizacji trzeba wykonać kilka dodatkowych czynności od strony bazy.
Ja mam problem z terminarzem tzn. jeśli jest dodana konkretna poradnia do terminala danego użytkownika to nie może on wejść do modułu bo go wywali i rozłączy program z bazą danych. Próba dodania tego gabinetu u użytkowników, którzy nie mają go dodanego, także powoduje ten sam problem. Problem pojawił się po aktualizacji do wersji 2016.03.1.06 wgranie 2016.03.1.07 nic nie pomogło. Baza Oracle błąd -ORA-03113: koniec pliku w kanale komunikacyjnym.
Niestety u mnie problem znów powrócił tym razem w module ZLECENIA->WYKONANIE. Paraliż straszny każdy rozkłada ręce. Troszkę boję się resetowania serwera bo mamy integracje z RIS, MEDISA i inne pierdoły. Jeśli ma ktoś jakieś pomysły co można zrobić to jestem otwarty na propozycję.
może być spowodowany fizycznym uszkodzeniem bazy danych.Ale nie musi ;)
może być spowodowany fizycznym uszkodzeniem bazy danych.Ale nie musi ;)
Jeżeli wykona się poprawnie to znaczy, że Somed nie radzi sobie ze zwracanym wynikiem bo jest z jakiegoś powodu niestandardowy. Tu też może pomóc update na bazie albo poprawka w Somed ;)
Oczywiście, to tylko jeden ze znanych mi scenariuszy, chciałbym tylko raz jeszcze sugerować, opis błędu wyraźnie mówi o problemach pomiędzy klientem a serwerem oracle. SOMED nie ma tu nic do tego. Tak przynajmniej wszystkie dostępne mi informacje o tym błędzie mówią.
Czasami włączenie jednej opcji może spowodować, np niemożność dodawania zleceń do systemu (ponieważ Somed inicjuje transakcję ex w trakcie trwania transakcji ex, co powoduje błąd oracle i wywołanie rollback przez Somed - taki błąd ostatnio rozwiązywałem).Ależ oczywiście, tyle, że rozważamy tu problem całkiem innej natura. Ten konkretny błąd oracle, o tym konkretnym numerze. I tu się upierać będę, to jest błąd komunikacji Oracle (klient - serwer)
Ps. W większości programów klienckich wystarczy nacisnąć ctrl+end aby przejść na koniec listy wyników co powoduje pobranie wszystkich rekordów wynikowych z bazy.Jasne, ale w tym rozwiązaniu nie wiemy kiedy się wywali. idąc rekord po rekordzie możemy ocenić np. o jakich pacjentów mogło chodzić. Co nie zmienia faktu, że sam bym skoczył kombinacja na koniec aby powiedzieć: moja rola się skończyła SOMED nic tu do tego nie ma, sprawdź bazę.
Ależ oczywiście, tyle, że rozważamy tu problem całkiem innej natura. Ten konkretny błąd oracle, o tym konkretnym numerze. I tu się upierać będę, to jest błąd komunikacji Oracle (klient - serwer)Za docs.oracle.com: