Program Płatnik nie jest w stanie rozpoznać wersji bazy danych – jak naprawić?

Problem objawia się najczęściej po niepełnej aktualizacji programu, gdy struktura bazy nie odpowiada uruchomionej wersji Płatnika. Podstawową przyczyną jest brak automatycznej konwersji bazy, co blokuje dostęp do danych płatnika. Niejednokrotnie zdiagnozowanie źródła usterki oraz jej usunięcie da się przeprowadzić bez telefonu na infolinię ZUS, korzystając z odpowiednich narzędzi naprawczych i porad dla administratora.

Jakie są źródła komunikatu o nierozpoznanej bazie?

Bezpośrednią przyczyną problemu jest niespójność pomiędzy aplikacją a miejscem przechowywania dokumentów. Usterka dotyczy zarówno środowisk opartych na plikach Access, jak i na serwerze Microsoft SQL. Program w trakcie uruchamiania porównuje swoją metrykę z metadanymi zapisanymi w tabelach i gdy napotyka rozbieżność, wyświetla ostrzeżenie bez wskazywania szczegółów technicznych.

Z praktyki administratorów wynika, że okolicznościami sprzyjającymi wystąpieniu komunikatu są zmiany w infrastrukturze sieciowej oraz aktualizacje wykonywane przy otwartej bazie. W takim przypadku pliki tymczasowe nie nadpisują się poprawnie, a moduł odpowiedzialny za sprawdzenie wersji nie może dokończyć walidacji.

Dlaczego aktualizacja często kończy się błędem?

Proces pobierania komponentów może zostać przerwany przez oprogramowanie zabezpieczające albo restrykcyjne polityki dostępu do katalogów C:\ProgramData\Asseco Poland SA. Wersja 10.02.002, publikowana na oficjalnej stronie Zakładu Ubezpieczeń Społecznych, wymaga obecności metryki 320, wdrożonej komunikatem technicznym z 23 stycznia 2026. Jeżeli antywirus lub firewall zablokuje transfer, Płatnik uruchomi się ze starszą metryką, co wywołuje konflikt z nowszą strukturą bazy.

Pośpiech przy zamykaniu programu również ma znaczenie. Gdy baza jest używana przez innego użytkownika w sieci, instalator aktualizacji nie może założyć blokady na plikach i pomija najbardziej istotne kroki konwersji. Dopiero restart środowiska i ponowne uruchomienie w trybie administratora pozwalają instalatorowi przejąć wyłączny dostęp do danych.

Jak zabezpieczyć dane przed naprawą?

Wykonanie kopii bazy jest absolutnie pierwszą czynnością, ponieważ błędnie przeprowadzona reinstalacja lub polecenie SQL może nieodwracalnie usunąć dokumenty zgłoszeniowe i rozliczeniowe. Odpowiedzialne postępowanie nakazuje zapisać kilka dodatkowych parametrów: aktualną datę i godzinę wykonania backupu, dokładną lokalizację pliku lub instancji serwera oraz rodzaj zastosowanego silnika – Access albo SQL Server.

Czym różni się backup w Access i SQL Server?

W przypadku pliku .mdb wystarczy skopiować go na inny nośnik, ale nie wystarczy samo powielenie katalogu programu. Warto zanotować ścieżkę oraz wersję Płatnika, z którą baza współpracowała przed awarią. Dla środowiska Microsoft SQL niezbędne jest uruchomienie SQL Server Management Studio i wykonanie polecenia BACKUP DATABASE PlatnikDB TO DISK po wcześniejszym potwierdzeniu nazwy bazy.

Zebranie informacji już na tym etapie pozwala uniknąć zgadywania podczas ewentualnego odtwarzania. Równie ważna jest znajomość nazwy instancji, ponieważ w organizacjach często istnieje kilka równoległych serwerów SQL, a odwołanie do niewłaściwego zakończy się fiaskiem.

Jak przeprowadzić wstępną diagnostykę?

Najskuteczniejszą ścieżkę stanowi uporządkowana lista sprawdzeń, wykonywana krok po kroku, zamiast chaotycznego instalowania wszystkich dostępnych poprawek. Na początku zapisujemy pełną treść komunikatu, a potem weryfikujemy, czy używamy najnowszej wersji pobranej z witryny ZUS. Praca na starym skrócie do innej instalacji bywa zaskakująco częstym powodem błędu.

Jakie uprawnienia są konieczne do diagnozy?

Osoba przystępująca do naprawy musi mieć możliwość administrowania daną instalacją oraz dostęp do konta Windows z profilem, na którym działa Płatnik. Dotyczy to zarówno uprawnień do katalogu C:\Program Files\Asseco Poland SA, jak i do bazy SQL, gdzie konto używane przez aplikację nie może być zablokowane lub pozbawione roli db_owner. Stan uprawnień da się szybko zweryfikować w SSMS za pomocą zapytania diagnostycznego łączącego widoki sys.database_principals i sys.database_permissions.

Bez aktualnej kopii zapasowej nie wolno usuwać bazy, przenosić plików ani ręcznie ingerować w strukturę tabel. Ryzyko utraty dokumentacji ubezpieczonych jest zbyt duże.

Jak sprawdzić stan usług i połączeń sieciowych?

Jeśli baza znajduje się na SQL Server, pierwszym ruchem jest upewnienie się, że usługa działa i że nazwa instancji nie uległa zmianie po migracji serwera. W przypadku baz plikowych sprawdzamy, czy ścieżka UNC do pliku .mdb jest osiągalna, a login użytkownika nie wygasł. Przydatne narzędzie to ponowne uruchomienie aktualizacji z oficjalnego źródła – często to właśnie ponowna transmisja nadpisuje źle pobrane komponenty.

Które narzędzia i metody naprawcze potwierdziły skuteczność?

Społeczność użytkowników wypracowała kilka sprawdzonych schematów działania. Najprostszy wykorzystuje oficjalny plik P2StartFix.exe, który wymusza pobranie brakujących komponentów. W przypadkach uporczywych konieczne staje się wyczyszczenie rejestru i zbudowanie tymczasowego środowiska testowego, co pozwala przebrnąć przez aktualizację bez ryzyka uszkodzenia właściwych danych.

Zebrane z forów dyskusyjnych relacje wskazują, że kluczowym momentem jest doprowadzenie do konwersji bazy przy pierwszym uruchomieniu programu jako administrator. Jeżeli ten etap zostanie pominięty, baza nie zyskuje nowych kolumn, czego objawem bywa błąd o braku pola III_PPK w tablicach UBEZP_SKLAD i UBEZP_ZUSRCA. Takie komunikaty świadczą o tym, że struktura nie została uzupełniona o dane wymagane przez pracownicze plany kapitałowe.

Na czym polega czyszczenie klucza rejestru?

W gałęzi HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Asseco Poland SA\Płatnik\10.02.002\Parametry znajduje się wartość przechowująca datę ostatniego pobrania pakietów. Wyczyszczenie tego wpisu sprawia, że przy kolejnym starcie Płatnik traktuje się jako nieaktualny i inicjuje długi proces ściągania plików. Metoda ta sprawdza się zwłaszcza po globalnej awarii aktualizacji, gdy serwery ZUS dostarczyły niepełną paczkę słowników.

Operacja wymaga uprawnień administratora i ponownego uruchomienia komputera. W środowiskach 64-bitowych dodatkowo należy pamiętać o włączeniu trybu zgodności oraz trwałym zaznaczeniu opcji „Uruchom ten program jako administrator” we właściwościach pliku P2.exe.

Jak wykorzystać tymczasową bazę Access do przeskoczenia błędu?

Jeden z udokumentowanych scenariuszy zakłada całkowitą reinstalację z usunięciem katalogów Asseco zarówno w Program Files, jak i ukrytym ProgramData. Instalator uruchamiany jest z opcją utworzenia nowej, pustej bazy Access. Następnie logujemy się, wprowadzamy fikcyjne dane płatnika i wykonujemy aktualizację z pliku metryczka_XML, a później jeszcze raz – już online. Dopiero po pomyślnym przejściu wszystkich etapów aktualizacji na testowej bazie przełączamy kontekst na właściwą bazę produkcyjną, która dzięki temu zostaje bezpiecznie rozpoznana.

Ta droga radzi sobie także z błędem weryfikacji podpisu metryki, który objawia się komunikatem „Niepoprawny format podpisu pod metryką” i wynika z braku aktualnych bibliotek kryptograficznych w starszej instalacji.

Czego unikać, aby nie pogorszyć sytuacji?

Ręczne zmiany w poziomie zgodności bazy, uruchamiane poleceniem ALTER DATABASE PlatnikDB SET COMPATIBILITY_LEVEL, są uzasadnione dopiero po analizie administratora SQL i tylko wtedy, gdy backup jest potwierdzony. Zbyt wczesne wykonanie tej komendy maskuje objaw, ale nie likwiduje faktycznej niespójności między metryką a strukturą tabel. Podobne ryzyko niesie masowe czyszczenie uprawnień – zablokowanie konta usługi na serwerze bazy skutkuje całkowitym odcięciem wszystkich stanowisk.

Jeśli baza zawiera realne dane płatnika, priorytetem jest zachowanie dokumentów, a nie natychmiastowe pozbycie się komunikatu. Każdą ręczną ingerencję dokumentuj i wykonuj dopiero po uzgodnieniu z właścicielem danych.

Kiedy warto wrócić do podstawowych komponentów systemu?

Problemy z podpisem metryki lub uruchamianiem aktualizacji często wynikają ze zdezaktualizowanych bibliotek, takich jak Parser XML 6.0, .NET Framework w wersji minimum 4.7.2 czy Microsoft Visual C++ 2010 SP1 Redistributable Package. W skrajnych przypadkach pomaga całkowite odinstalowanie Płatnika, restart, ręczne usunięcie pozostałości wpisów rejestru i dopiero wówczas świeża instalacja z plikiem uzyskanym z witryny ZUS.

Wielu administratorów pomija etap restartu albo próbuje nadpisać pliki bez czyszczenia katalogów tymczasowych. Tymczasem pozostawienie starych plików konfiguracyjnych sprawia, że instalator odczytuje poprzednią, wadliwą ścieżkę aktualizacji i cykl problemu się powtarza.

Jak porównać metody naprawcze?

W zależności od rodzaju bazy i dostępu do infrastruktury efektywność poszczególnych ścieżek bywa różna, co można zestawić w formie tabeli porównawczej:

Zestawienie pokazuje, że narzędzie P2StartFix jest najszybsze, ale nie poradzi sobie, gdy problemem jest głęboka niezgodność strukturalna, na przykład po rocznej przerwie w aktualizacjach. Wtedy pełna reinstalacja okazuje się bardziej przewidywalna.