Program Płatnik nie jest w stanie rozpoznać wersji bazy danych – co robić?

Komunikat „Program Płatnik nie jest w stanie rozpoznać wersji bazy danych” oznacza, że aplikacja utraciła spójność z zapleczem przechowującym dokumenty, co blokuje dalszą pracę. Taka sytuacja najczęściej wynika z przerwanej aktualizacji lub uszkodzenia struktury plików. Poniższy tekst zawiera szczegółową ścieżkę diagnostyki i naprawy, która pomoże Ci bezpiecznie przywrócić dostęp do danych.

Co naprawdę oznacza błąd nierozpoznanej wersji bazy?

Ten specyficzny alert nie jest zwykłą usterką startową. Wskazuje on, że mechanizm programu nie potrafi zweryfikować, czy struktura obecnej bazy danych Płatnika pasuje do uruchomionej wersji oprogramowania. Problem może ujawnić się po niepełnej aktualizacji Płatnika, po awarii usługi SQL Server, po przeniesieniu plików na inny dysk lub gdy użytkownik próbuje otworzyć nowszą bazę w starszej aplikacji.

W praktyce ekran logowania pozostaje nieaktywny, ponieważ rdzeń systemu nie może potwierdzić integralności tabel. W środowiskach korzystających z silnika SQL Server administrator może szybko zweryfikować podstawowy stan za pomocą zapytania diagnostycznego. Wykonane w SSMS (SQL Server Management Studio) polecenie SELECT name, compatibility_level FROM sys.databases WHERE name = 'PlatnikDB’; nie zmienia danych, ale pozwala ocenić, czy instancja w ogóle widzi pliki. Sam odczyt poziomu zgodności bazy SQL to jednak za mało, by postawić diagnozę – konieczne jest sprawdzenie konfiguracji klienta.

W przypadku wariantu plikowego, jaki oferuje Access, kluczowe jest fizyczne istnienie pliku z rozszerzeniem .mdb w lokalizacji wskazanej w konfiguracji. Częstą przyczyną jest tu zwykłe przeniesienie zasobu sieciowego bez aktualizacji ścieżki w ustawieniach stanowiska. Dlatego pierwszą czynnością zawsze musi być ustalenie, czy połączenie z właściwym magazynem jest w ogóle możliwe.

Jak zabezpieczyć dane przed rozpoczęciem naprawy?

Priorytetem jest ochrona wszystkich zgromadzonych dokumentów i deklaracji. Bezwzględnie należy rozpocząć od utworzenia pełnej kopii bazy danych. Dla środowiska opartego o SQL Server rolę tę musi przejąć administrator SQL, który za pomocą SQL Server Management Studio wykona backup techniczny. Osoba posiadająca uprawnienia powinna użyć schematu: BACKUP DATABASE PlatnikDB TO DISK = 'C:\backup\PlatnikDB.bak’;. Nazwa pliku i ścieżka muszą być bezwzględnie dostosowane do realiów danej firmy.

Gdy firma opiera się na plikowej bazie Access, wystarczy skopiować właściwy plik .mdb, pamiętając, że nie może on być w tym momencie otwarty przez nikogo w sieci. Nie wystarczy archiwizacja katalogu programu – plik bazy często rezyduje w zupełnie innej lokalizacji wskazanej w konfiguracji startowej. Zanotuj także precyzyjnie: datę i godzinę kopii, lokalizację bazy, jej typ oraz wersję programu Płatnik (np. 10.02.002). Brak tego zestawienia może uniemożliwić późniejsze odtworzenie stanu sprzed awarii.

Bez aktualnej kopii zapasowej nie wykonuj reinstalacji, ręcznych zmian w SQL ani przenoszenia plików. Takie działania mogą nieodwracalnie zniszczyć dane płatnika.

Diagnostyka i uprawnienia – od czego zacząć?

Aby skutecznie usunąć awarię, potrzebny jest dostęp do profilu z pełnymi prawami administracyjnymi, zarówno w systemie Windows, jak i na poziomie bazy. Zanim przejdziesz do modyfikacji, zweryfikuj podstawy: czy nazwa instancji SQL Server nie uległa zmianie po aktualizacji sprzętu oraz czy usługa SQL Server jest w stanie aktywnym. W wielu przypadkach za błąd odpowiada też blokada nałożona przez firewall i antywirus, uniemożliwiająca komunikację sieciową z serwerem.

Jeśli wstępna kontrola wypada pozytywnie, a dostęp nadal jest blokowany, należy skontrolować zakres uprawnień konta bazy. Możesz to uczynić analitycznym zapytaniem, które odczytuje informacje z widoków systemowych: SELECT dp.name, dp.type_desc, dpr.permission_name FROM sys.database_principals dp JOIN sys.database_permissions dpr ON dp.principal_id = dpr.grantee_principal_id WHERE dp.name = 'platnik_user’;. Oczywiście zamiast 'platnik_user’ wstaw nazwę konta serwisowego używanego w twoim środowisku. Jeżeli lista uprawnień jest niepełna, a administrator SQL potwierdzi konieczność eskalacji, może on jawnie nadać rolę właściciela poleceniem ALTER ROLE db_owner ADD MEMBER platnik_user;. To radykalny krok, wykonywany tylko po upewnieniu się, że operacja dotyczy wyłącznie dedykowanej bazy produkcyjnej Płatnika.

W firmach stosujących wielostanowiskową pracę Płatnika częstym błędem jest próba aktualizacji bazy, gdy na innym komputerze jest ona otwarta. Zawsze przed uruchomieniem procedur naprawczych upewnij się, że wszyscy pozostali użytkownicy wylogowali się z systemu.

Jak przywrócić spójność, gdy automatyczna aktualizacja zawodzi?

Główną osią problemu po publikacji nowej wersji jest rozjechanie się metryk. Metryka 320, wdrożona dla edycji 10.02.002 z datą 23 stycznia 2026 roku, powinna być pobierana automatycznie. Jeśli tak się nie dzieje, wynika to z błędnego znacznika czasu w rejestrze. Z pomocą przychodzi tu narzędzie udostępniane oficjalnie – P2StartFix, czyli plik P2StartFix.exe. Jego uruchomienie (bezwzględnie z opcją „Uruchom jako administrator”) resetuje pamięć podręczną, wymuszając na module NUpdater ponowne sięgnięcie na serwery ZUS.

Jeśli samo narzędzie nie wystarcza, trzeba ręcznie usunąć wartość odpowiedzialną za zapis daty ostatniego pobrania. Klucz znajduje się w gałęzi: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Asseco Poland SA\Płatnik\10.02.002\Parametry. Po zlokalizowaniu wpisu rejestru DataPobraniaPakiety wystarczy wyczyścić jego zawartość, pozostawiając puste pole. Po zapisaniu zmian i uruchomieniu aplikacji (z konta administratora), powinien ruszyć wymuszony proces ściągania poprawnych pakietów.

Komunikat „Błąd podczas NUpdater.DajMetryke: Niepoprawny format podpisu pod metryką” oznacza, że program dysponuje błędną wersją bibliotek kryptograficznych i nie przeszedł pełnej aktualizacji składników.

Zaawansowana rekonstrukcja przez reinstalację i bazę pomostową

Gdy żadne próby czyszczenia rejestru nie dają efektu, konieczna staje się procedura „czystej” instalacji z utworzeniem tymczasowej, pomostowej bazy. Potwierdzają to doświadczenia administratorów, którzy na forach dzielili się skuteczną 18-krokową metodą. Fundamentem jest tu całkowite usunięcie wszystkich pozostałości starej aplikacji.

Procedura zaczyna się od deinstalacji Płatnika i restartu systemu. Następnie trzeba ręcznie usunąć pozostałe katalogi, pamiętając, że katalog ProgramData (domyślnie C:\ProgramData) jest w systemie ukryty. Po skasowaniu folderów Asseco w Program Files (x86) i ProgramData, należy w edytorze rejestru dotrzeć do ścieżki właściwej dla architektury systemu i dokonać usunięcia wpisu rejestru Asseco. Dopiero po tych działaniach i kolejnym restarcie można pobrać pełny instalator ze strony ZUS.

Tworzenie tymczasowej bazy Access

W kreatorze instalacji kluczowe jest zaznaczenie opcji utworzenia nowej bazy testowej Access. To właśnie na tym pustym, nieskażonym błędem środowisku będziemy w stanie przeprowadzić pełną sekwencję aktualizacji. Gdy instalator zakończy pracę, aplikacji nie uruchamiamy od razu – najpierw stosujemy narzędzie P2StartFix.

Po pierwszym uruchomieniu Płatnika (nie ściągając jeszcze żadnych nowych wersji online), logujemy się do tej czystej bazy. System wymusi walidację NIP płatnika, dlatego w tym miejscu podaje się dane tzw. fikcyjnego płatnika. Mogą to być dane istniejącego podmiotu – kreator i tak wymaga pozytywnej weryfikacji, by przejść dalej i dodać podmiot do kontekstu pracy.

Ręczna i automatyczna aktualizacja metryki

Mając załadowany pusty profil, przechodzimy do sekcji narzędziowych programu. Z menu wybieramy funkcję instalacji nowej wersji z pliku, wskazując wcześniej przygotowaną paczkę PakietAktualizacji.zip. Wewnątrz niej znajduje się kluczowy komponent: plik metryczka_XML. To właśnie on przeprowadza strukturalną przebudowę tabel. Po zakończeniu tego etapu i restarcie aplikacji, system dokona konwersji bazy danych – nadal tej pustej.

Dopiero gdy w testowym środowisku wszystkie metryki (np. przejście ze starszej metryki 202 do docelowej 208) zostaną pozytywnie zweryfikowane, uruchamiamy aktualizację online. Pobiera ona certyfikaty i drobne łatki. Na samym końcu, gdy w dziale aktualizacji nie ma już żadnych zaległości, programista lub administrator wykorzystuje funkcję „Zmień bazę danych”, aby ponownie podpiąć się pod właściwą, oryginalną bazę SQL lub Access, która od tego momentu powinna zostać rozpoznana przez kreator.

Ostrzeżenia i ślepe uliczki, których unikać

Nigdy nie wprowadzaj ręcznych modyfikacji w strukturze tabel, jeśli nie pochodzi to z oficjalnych wytycznych. Dotyczy to zwłaszcza pokusy bezpośredniego dodawania pól. Historie z forów pokazują, że po wdrożeniu PPK (Pracowniczych Planów Kapitałowych), w tabelach UBEZP_SKLAD i UBEZP_ZUSRCA brakowało fizycznych kolumn, co blokowało logowanie. Próba samodzielnego wstawienia tych pól nie rozwiązuje problemu – jedynym lekarstwem jest oficjalny skrypt konwersji.

Unikaj także zmiany daty systemowej na archaiczną (np. 1 lipca 2020), chyba że jest to absolutnie ostateczny krok w procedurze diagnostycznej. Obejścia w stylu cofania czasu systemowego psują logi systemowe i ważność innych kluczy. Jeszcze bardziej niebezpieczne jest ręczne ustawianie poziomu zgodności bazy SQL za pomocą ALTER DATABASE COMPATIBILITY_LEVEL. Choć polecenie ALTER DATABASE PlatnikDB SET COMPATIBILITY_LEVEL = 150; jest technicznie poprawne dla niektórych wersji SQL, jego bezrefleksyjne wykonanie może pogłębić rozjazd metadanych aplikacji i silnika.

Dodatkowo, przed każdą reinstalacją warto sprawdzić wersje wymaganych komponentów systemowych. Brak Parser XML 6.0, nieaktualny .NET Framework 4.8 czy niedobór paczki Microsoft Visual C++ 2010 SP1 Redistributable często skutecznie uniemożliwiają poprawne podpisanie metryki przy starcie.