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

Komunikat ten oznacza, że struktura bazy danych jest niekompatybilna z uruchomioną wersją programu Płatnik, co najczęściej wynika z nieukończonej aktualizacji lub braku uprawnień do jej przeprowadzenia. Bezpieczna naprawa wymaga wykonania kopii zapasowej i przeprowadzenia sekwencyjnej diagnostyki. Szczegółowe instrukcje oraz sprawdzone metody rozwiązania tego problemu znajdziesz w dalszej części artykułu.

Co dokładnie oznacza błąd nierozpoznanej wersji bazy?

Alert „Program Płatnik nie jest w stanie rozpoznać wersji bazy danych” to sygnał od aplikacji, że jej silnik nie potrafi bezpiecznie zidentyfikować struktury przechowywanych danych. Nie jest to zwykły błąd startowy, który można zignorować – dotyczy on integralności całego środowiska, w którym zapisane są dokumenty zgłoszeniowe i rozliczeniowe. Przyczyny mogą być różnorodne, od przerwanej procedury aktualizacyjnej, przez niekompatybilność komponentów, aż po problemy z uprawnieniami w systemie operacyjnym lub na serwerze SQL.

Aplikacja podczas startu porównuje swoją wewnętrzną metrykę z faktycznym stanem bazy. Jeśli proces ten zostanie zakłócony – na przykład przez blokadę plików lub niedostateczne prawa dostępu – program nie jest w stanie kontynuować pracy i wyświetla omawiany komunikat. Sytuacja taka często ma miejsce po wdrożeniu nowej wersji oprogramowania, gdy pliki aplikacji zostały już nadpisane, ale baza nie przeszła jeszcze wymaganej konwersji.

Zabezpieczenie danych przed jakimikolwiek działaniami

Podjęcie prób naprawczych bez aktualnej kopii zapasowej jest największym ryzykiem, jakie możesz podjąć. Bez względu na to, jak pilna jest potrzeba wysyłki dokumentów, pierwszym i niepodważalnym krokiem musi być wykonanie backupu. W przypadku baz typu MS Access polega to na fizycznym skopiowaniu pliku z rozszerzeniem .mdb na bezpieczny nośnik. W środowisku SQL Server niezbędne jest użycie programu SQL Server Management Studio (SSMS) do wykonania pełnego backupu bazy PlatnikDB.

Wprost krytycznym działaniem jest reinstalacja programu, usuwanie plików danych czy ręczne modyfikacje wpisów w rejestrze przed upewnieniem się, że kopia jest kompletna i możliwa do odtworzenia. Administrator powinien w tym momencie zanotować dokładną lokalizację bazy, jej typ, wersję programu Płatnik oraz pełną treść wyświetlanego komunikatu. Te informacje będą fundamentem dalszej diagnozy.

Bez potwierdzonej kopii zapasowej nie należy wykonywać reinstalacji, ręcznych zmian w SQL ani żadnych operacji na plikach bazy. Priorytetem jest zachowanie danych płatnika i ubezpieczonych, a nie szybkie usunięcie komunikatu błędu.

Weryfikacja wersji i integralności aktualizacji

Rozbieżność między wersją programu a stanem bazy to częsta konsekwencja niekompletnie pobranych pakietów aktualizacyjnych. Oficjalnym źródłem oprogramowania jest serwis ZUS, a wersją publikowaną w chwili obecnej (2026 rok) jest Płatnik 10.02.002 z metryką 320. Informację o wdrożeniu tej metryki dla wspomnianej wersji ogłoszono w komunikacie technicznym z 23 stycznia 2026 roku. Jeżeli błąd wystąpił bezpośrednio po aktualizacji, należy prześledzić, czy cały proces zakończył się sukcesem.

Do podstawowych punktów kontrolnych należy sprawdzenie, czy program był uruchamiany z uprawnieniami administratora oraz czy żaden inny użytkownik sieci nie korzystał w tym czasie z bazy. W środowisku wielostanowiskowym otwarta sesja innego komputera całkowicie blokuje proces konwersji. Równie istotne jest upewnienie się, że skrót na pulpicie wskazuje na właściwą instalację – zdarza się, że po reinstalacji w systemie pozostaje odwołanie do starej, nieaktualnej wersji programu, który próbuje odczytać bazę przeznaczoną już dla nowszej wersji.

Diagnostyka problemów z uprawnieniami i połączeniem

Program Płatnik do poprawnego działania wymaga nie tylko dostępu do własnych plików, ale także odpowiednich uprawnień w systemie Windows i na serwerze bazy danych. Jeżeli w firmie obowiązuje polityka ograniczonych praw użytkownika, samo uruchomienie aplikacji z opcją „Uruchom jako administrator” może być pierwszym, skutecznym rozwiązaniem. W przypadku baz SQL Server należy zweryfikować, czy konto użytkownika, na którym pracuje Płatnik, nie zostało zablokowane lub pozbawione niezbędnych praw po niedawnej migracji infrastruktury.

Administrator bazy danych może w tym celu posłużyć się dedykowanym zapytaniem diagnostycznym w SSMS, które nie modyfikuje danych, a jedynie odczytuje informacje o nadanych uprawnieniach. Jeżeli okaże się, że właściwe konto nie ma pełnych praw, a jest to zgodne z polityką bezpieczeństwa firmy dla tego środowiska, można je jawnie nadać, przypisując rolę db_owner do użytkownika bazy Płatnika. Taka operacja musi być jednak wykonana świadomie i wyłącznie dla dedykowanej bazy PlatnikDB.

Jak krok po kroku przywrócić sprawność programu?

Gdy standardowe podejścia zawodzą, a ponowne uruchamianie aktualizacji nie przynosi rezultatu, skuteczną metodą okazuje się kontrolowane odtworzenie środowiska z wykorzystaniem tymczasowej, pustej bazy. Technika ta pozwala na wymuszenie pełnego cyklu aktualizacji komponentów programu, a następnie bezpieczne podmienienie ścieżki na właściwą bazę danych. Poniższa procedura została zweryfikowana w wielu przypadkach uporczywego braku rozpoznawania wersji bazy.

Przygotowanie czystego środowiska

Rozpocznij od całkowitego odinstalowania programu Płatnik za pomocą Panelu sterowania. Po zakończeniu dezinstalacji uruchom ponownie komputer, co jest niezbędne do zwolnienia wszystkich blokad systemowych. Następnie ręcznie zweryfikuj i usuń pozostałości po aplikacji – katalog w Program Files (x86)\Asseco Poland SA\Płatnik oraz ukryty folder ProgramData\Asseco Poland SA. Ten drugi jest szczególnie ważny, gdyż przechowuje dane konfiguracyjne i pamięć podręczną, które mogą zakłócać nową instalację.

Instalacja z nową bazą testową

Pobierz najnowszy instalator programu ze strony ZUS, a także narzędzie naprawcze P2StartFix.exe. Uruchamiając instalację, zwróć szczególną uwagę na wybór typu bazy danych – należy wskazać MS Access i koniecznie zaznaczyć opcję utworzenia nowej, pustej bazy. Po zakończeniu instalacji, ale przed pierwszym uruchomieniem Płatnika, zastosuj plik P2StartFix. Narzędzie to resetuje parametry aktualizacji, co jest kluczowe dla powodzenia całego procesu.

Wymuszenie pełnej aktualizacji przez tymczasowego płatnika

Uruchom program Płatnik i powstrzymaj się od pobierania aktualizacji online na tym etapie. W całkowicie pustej bazie załóż fikcyjnego płatnika, wprowadzając dane i weryfikując je, a następnie wybierz go do kontekstu pracy. Przejdź do sekcji narzędzi i wybierz opcję instalacji nowej wersji z pliku – w tym miejscu wskaż rozpakowaną wcześniej metrykę XML. Program przeprowadzi restart i dokona konwersji bazy testowej.

Dopiero po pomyślnej aktualizacji z pliku możesz uruchomić aktualizację online, która pobierze pozostałe komponenty bezpośrednio z serwera ZUS. Po jej zakończeniu i ponownym restarcie aplikacji, sprawdź zakładkę przekazu i ustawień certyfikatów. Gdy wszystkie procesy aktualizacyjne na testowej bazie zakończą się sukcesem, masz pewność, że program jest w pełni spójny i aktualny. Ostatnim krokiem jest wybranie opcji zmiany bazy danych i wskazanie swojej właściwej bazy (SQL lub Access).

Rozwiązywanie problemów na stacjach roboczych

W środowiskach klient-serwer z bazą na SQL 2016 lub 2019 może wystąpić sytuacja, w której serwer przechodzi konwersję poprawnie, ale wybrane stacje robocze nadal zgłaszają błąd. Problem leży wtedy po stronie klienta, a nie serwera. Na niedziałającej stacji należy wykonać analogiczne czyszczenie rejestru, ręcznie usuwając wpis DataPobraniaPakiety w gałęzi HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Asseco Poland SA\Płatnik\10.02.002\Parametry. Program uruchomiony po tej zmianie ponownie wymusi pobranie aktualizacji z serwera i powinien nawiązać połączenie z już skonwertowaną bazą.

Co robić, gdy naprawa nie przynosi efektu?

Jeżeli żadne z powyższych rozwiązań nie usuwa komunikatu, a błąd pojawia się na świeżo postawionym systemie, sytuacja staje się bardziej złożona. W takich przypadkach sprawdzoną ścieżką awaryjną, potwierdzoną przez doświadczonych administratorów, jest utworzenie kolejnej nowej bazy Access i odtworzenie danych z kopii archiwalnej. Proces ten omija problem uszkodzonej struktury, tworząc całkowicie nowy plik .mdb i importując do niego historyczne dane zgłoszeniowe i rozliczeniowe. Niestety, jest to operacja czasochłonna, ale często okazuje się jedyną skuteczną metodą w skrajnych przypadkach.