SOMED + oracle problem z klientem

[neelix]

Witam.

Mam SOMEDa ma oracle, po aktualizacji do ostatniej wersji 2010.00.0.03 klient przy uruchomienu wyrzuca komunikat: "Wersja baz jest nowsza od wersji programu!". Program zainstalowany na jednym kompie z serwerem działa. Teoretycznie przy starcie klienta masamaściągnąc aktualizacje i rzeczywiście ściąga coś, ścieżka do automatycznych aktualizacji jest poprawna "\\Serwer\KS-PLW\aktualizacje\" ale komunikat pozostaje. Nie pomogło uruchomienie COPYKPSL.EXE na serwerze, w kamsofcie poradzili skopiować ręcznie cały katalog z działającego kompa ale też nie pomaga. Może znaczenie ma to że serwer i działająca wersja pracuje na XP 64bit a klient na zwykłym XP HOME?
Oczywiście na infolinii w Katowicach przez dwa dni nikt nie odbiera telefonu. 

[MK]

Proszę sprawdzić datę i wersję pliku ksplkonfig.dll Powinien być z 26 stycznia, jesli mowa o wesji 2010.00.0.03.
Co prawda nowa wersja potrafi skorzystać z funkcjonalności XP i wyższych i podmienić plik, nawet jeśli jest zablokowany przez inny proces, ale zdarzają się sytuacje, o których nie śniło się filozofom. Czasem w tle coś biega i blokuje aktualizację konkrentej dll.
Jeśli ksplkonfig.dll jest w innej wersji, to znaczy starszej, proszę "na siłę" spróbować go przekopiować.

[neelix]

Dziękuje za odpowiedź. Istotnie ten plik na klienci jest z listopada 2009. Podmieniam go nawersje ze stycznia 2010 ale po uruchomieniu programu mam taki sam komunikat a co ciekawsze po tym plik automatycznie podmienia się na tą starszą wersję z listopada.


Jednak pomogło, musiałem usunąć ścieżkę automatycznej aktualizacji, plik pozostał w nowej wersji i klient łączy się bez problemów. Coś jednak świadczy że jest problem z aktualizacjami, na tą chwilę działa, dziękuje za pomoc.

[MK]

No to proszę sprawdzić stan na komputerze, z którego się kopiuje!
Proszę też sprawdzić taki schemat: wycina Pan wpis sciezkadll, przekopiowuje ręcznie ksplkonfiga, uruchamia bez aktualizacji i sprawdza Pan, jaka jest wersja dll. Czy to jest tak w rzeczywistości to ja nie wiem, ale przynajmnije z bibliotekami windowsa o ile wiem jest tak, że ręcznie nie da się skopiować dllki bo system i tak przywróci oryginalną. Kto wie, może jakiś cudem to samo dzieje się z ksplkonfigiem (choć nie sądzę).

W każdym razie wycięcie ścieżki aktualizacji przynajmniej pozwoli sprawdzić, czy podmiana jest związanana z mechanizmem aktualizacji, czy też nie.

A tak delikatnie trzymając się tematu powiem tylko, że musieliśmy zmienić dla firebirda oryginalne rozszerzenie pliku bazy danych z gdb na ksb, bo w przypadku gdb niektóre systemy operacyjne uznawały, że jest to tak ważny plik systemowy, iż przy każdym pierwszym dostępem kopiowały plik do jakiegoś tajemniczego katalogu. Efekt - uruchomienie KS-SOMED trwało wieki! A wystarczyło zmienić rozszerzenie  . Jak się więc okazuje zawsze można trafić na jakiś ciekawy mechanizm systemu. Może "konfig" też jest jakoś szczególnie wyróżnany?

[neelix]

Tak właśnie zrobiłem, ścieżka aktualizacji jest usunięta i po podmianie ręcznej biblioteki pozostaje ta nowa działająca. Z tego rozumiem że SOMED przy uruchamianiu podmieniał sobie plik z lokalizacji automatycznej aktualizacji. Z tym tez kiedyś będę musiałzrobić porządek ale na razie import z PPSa, wczytanie umów, tworzenie listy i pierwsze rachunki. Jeszcze raz dziękuje za pomoc.

[MK]

Z tego rozumiem że SOMED przy uruchamianiu podmieniał sobie plik z lokalizacji automatycznej aktualizacji.

No tak. Ważne więc by TAM była właściwa wersja.