dzień dobry,
no i się zaczęło
Próba konwersji bazy z kdp2014a do 2014.1 wydaje się nie mieć końca program wisi dwa dni na naliczaniu zestawów do PIT ... postanowiłem puścić to naliczanie po konwersji (proces konwersji informuje o takiej możliwości) ... odtworzyłem kopię na innym komputerze, przeindeksowałem, zaktualizowałem do 2014.1 1 z okna okresy/Miesiące-Lata wykonałem nalicz dla roku 2013 ale jest tak samo ... W bazie jest około 250 osób ale większość na umowach o dzieło / prawach autorskich i to nie w każdym miesiącu (raz jeden raz drugi) ...
A jakie są Wasze doświadczenia i czy/jak ten proces można przyspieszyć?

Idziemy na rekord czy ktoś może pochwalić się "lepszym" wynikiem ? Operacje uruchomiłem równolegle na różnych maszynach (serwer2012+Xeon+PSQL i DualCore2,5GHz+Win7Pro Brtv z kilku godzinnym opóźnieniem na Win7) ale postęp jest taki sam!
Na litość Boską co się dzieje w tym SAGE-u? Rozumiem cięcie kosztów ale nie kosztem zatrudniania ludzi z przypadku! Co rok to jest gorzej! Może powiedzcie Klientom, że nie dajecie rady, wywieście białą flagę i się poddajcie bo to zadanie (ciągnięcie projektu pod tytułem Kadry i Płace) chyba Was przerosło!

Dodałem jeszcze listę okresów z wersji 2014a.
Jak długo powinienem jeszcze czekać?

Robert

Czy masz pervasive? z tego co widze to proces taki tam jest - wiec pytanie brzmi jaki masz ustaeiony rozmiar memory cache ( i czy jest on w>= od rozmiaru katalogu z baza? I czy wogole cache jest tam wlaczony? ( jesli masz btrieve tez to samo pytanie) no i czy dawno robiles rebuild tej bazy?

dzięki za zainteresowanie naliczanie zakończone !
co do konfiguracji:
rebiuld zrobiłem tuż przed konwersją (baza zmalała z 500 MB do 370 MB - jeśli dobrze pamiętam)
Konwersję uruchomiłem równolegle na dwóch różnych maszynach z pervasivem i bez i wyniki są bardzo porównywalne.
na jednej maszynie jest dysk SATA+BTR a na drugiej SAS+PSQL w obu jest UseCascheEngine=off i oczywiście naliczanie włączyłem lokalnie a nie po sieci ... zrobiłem też próbę na SSD+PSQL ale wyniki były gorsze (bo ten komp miał słabszy procesor)
Ponadto w dokumentacji piszą:

więc ostrożnie podchodzę do użycia cache'a i nie sądzę aby to miało kluczowe znaczenie dla tego przypadku ... na wykresie użycia zasobów nie było widać, żeby program korzystał z dysku tylko z procesora i to na 100% (jednego rdzenia) zajęty był przez AMKD.exe przy minimalnym użyciu dysku.

Robert

Cache ma znaczenie krytyczne dla tego przypadku - bez niego moze liczyc ze 20 -30 razy dluzej i nie wiem czemu go wylaczyles - to jest bardzo zly pomysl - wlacz go i generalnie ustaw porzadnie parametry jego pamieci i wtedy testuj inaczje faktycznie pervasive bedzie mialo wyniki takie jak btrive albo i gorsze. A skoro robisz lokalnie to i te straszne 5 sekund cie nie dotycza :) :) zreszta z analiz na szybkiej sieci to nigdy nie przekracza 1 sek.....

dziękuję za włączenie się do dyskusji oraz za cenne rady ale pozwoli Kolega, że się z nim nie zgodzę, zrobiłem test z włączonym i wyłączonym cachem i wyniki są porównywalne. Z moich doświadczeń wynika, że kluczowe znaczenie na ilość okresów płacowych (u mnie jest kilka (4-5) od umów c-p i dwa z umowy o pracę) Przekonwertowałem do tej pory tylko kilka baz (z wersji 2014 do 2014.1) i jeśli był to 1 okres płacowy na 1 miesiąc to szło normalnie jeśli były dwa okresy w jednym miesiącu to szło około 4 razy dłużej...
A teraz poproszę Cię o zrobienie testu na firmie Demo_KD, nalicz okres listopad, sprawdź ile czasu zajmuje naliczenie dla Antkowiaka, przerwij proces , dodaj trzy miesiące dla UCP i w jednym z nich wstaw i rozlicz jakąś umowę, nalicz okres i sprawdź jaki dostaniesz wynik (u mnie było to 10 razy dłużej) i sprawdź jakie znacznie ma włączony i wyłączony cache potem wyobraź sobie bazę, która ma 5 razy więcej okresów płacowych i blisko 10 razy więcej pracowników ...

Na zakończenie tego wątku tylko dodam:
jedno jest pewne, naliczanie elementów PIT radzę robić po wykonaniu konwersji bazy danych - będzie można na tej bazie pracować (jeśli licencja jest wielostanowiskowa) no i jest mniejsze zagrożenie konieczności odtwarzania danych podczas jakiegoś niefortunnego zdarzenia.

pozdrawiam
Robert

Ja mam bazy z 15-20 okresów placowych w miesiącu - i bez problemu mi je nalicza i szybko (fakt ze 14 wolniej niz 13 ale tylko nieco wolniej) :)- i prosze zwróć uwagę czy masz ustawiony rozmiar cache tak gdzieś na rozmiar baz bo inaczej to szybkość naliczania jest mala jeżeli cache jest mały a baza duza
Aby nie było nieścisłości mowie tu o opcjach w configure local engine - performance tunning - cache allocation size oraz ponizej max microkenel memory usage - obie trzeba ustawic z sensem -szczególnie przy starszych wersjach pervasive

tu mała korekta nt ilości pracowników
BTW
A cache należy też włączyć w Configure MicroKernel Router ale zdecydowanie lepsze wzrost wydajności przynosi wyłączenie wszystkiego czego się da w Configure Local Engine / Debugging

pozdrawiam
Robert

ps niewykluczone, że ta baza ma coś z indexami ale przed konwersją zrobiłem rebuild a może powinienem zrobić Firma/Poprawność danych z Shiftem ?

Witam serdecznie,

mam podobny problem ale tylko z jednym pracownikiem. nalicza go trwa wieki. gdzie szukać rozwiązania?

To cieko powiedziec jezeli dotyczy tylko jednego pracownika - jezeli reindeksacja z programu nie pomaga to pozostaja albo zalozyc go od nowa albo poprosic o pomoc tego kto to wdrazal u Ciebie

Możesz mi podpowiedzieć jak dokonać reindeksacji?

W menu firma poprawnosc danych (przed wejciem do firmy)