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

Komunikat „Program Płatnik nie jest w stanie rozpoznać wersji bazy danych” oznacza, że aplikacja nie potrafi bezpiecznie zidentyfikować struktury swojego repozytorium. W większości przypadków problem da się rozwiązać przez ponowne pobranie aktualizacji i naprawę metryki, jednak wcześniej koniecznie trzeba zabezpieczyć istniejące dane. W dalszej części artykułu znajdziesz uporządkowany zestaw wskazówek, które pomogą Ci odzyskać sprawność programu bez ryzyka utraty plików.

Dlaczego pojawia się ten błąd?

Wystąpienie komunikatu o nierozpoznanej wersji bazy danych rzadko jest przypadkowe. Najczęściej jest efektem niepełnej aktualizacji Płatnika, podczas której nie zostały pobrane wszystkie komponenty lub metryka nie została poprawnie wczytana. Inną przyczyną bywa uruchomienie starszego programu na nowszej bazie – taka niespójność pojawia się po przeniesieniu komputera do innej domeny albo po ręcznej podmianie plików.

W środowiskach SQL Server przyczyną bywa również awaria SQL Server lub zmiana uprawnień do bazy. W takich wypadkach sam program działa poprawnie, ale nie jest w stanie odczytać struktury tabel z serwera. Zdarza się też, że problemem jest brak dostępu do katalogu tymczasowego lub blokada nałożona przez program antywirusowy.

W każdej z tych sytuacji system rejestruje błąd, zanim jeszcze pojawi się okno logowania. Dlatego kluczowe jest, by nie ignorować tego komunikatu i nie traktować go wyłącznie jak usterki startowej – dotyczy on bezpośrednio miejsca, w którym zapisane są wszystkie dokumenty zgłoszeniowe i ustawienia środowiska.

Jakie dane zabezpieczyć przed rozpoczęciem naprawy?

Zanim wykonasz jakąkolwiek czynność naprawczą, potwierdź, że dysponujesz aktualną kopią zapasową bazy. Bez tego nawet sprawdzone procedury, w tym reinstalacja czy czyszczenie rejestru, mogą skończyć się trwałym uszkodzeniem danych. W przypadku bazy SQL Server kopia powinna być wykonana przez administratora SQL z poziomu Management Studio – zwykłe skopiowanie plików nie wystarcza.

Przy bazie Access zabezpiecz fizyczny plik z rozszerzeniem .mdb, pamiętając, że nie wystarczy archiwizacja samego folderu programu. Równocześnie zanotuj następujące informacje: datę i godzinę kopii, lokalizację bazy, typ bazy – Access lub SQL Server, nazwę instancji SQL Server jeśli występuje, wersję programu Płatnik oraz dokładną treść komunikatu błędu. Te dane ułatwią późniejsze odtworzenie środowiska i pozwolą uniknąć pomyłek w trakcie diagnostyki.

Bez kopii zapasowej nie wykonuj reinstalacji, ręcznych zmian w bazie ani przenoszenia plików – priorytetem jest zachowanie danych.

Jak sprawdzić, czy używasz właściwej wersji i metryki?

Według komunikatu technicznego ZUS z 23 stycznia 2026, dla wersji 10.02.002 wdrożono metrykę 320. Oznacza to, że zarówno główny plik programu, jak i zbiór słowników muszą pochodzić z tego samego zestawu. Aktualizację należy zawsze pobierać z oficjalnej strony ZUS – wersje z nieautoryzowanych źródeł często nie zawierają poprawnych komponentów, co prowadzi właśnie do nierozpoznawania bazy.

Po instalacji sprawdź, czy metryka została pobrana automatycznie. Jeżeli po uruchomieniu aplikacji widzisz komunikat o błędzie, a wersja głównego pliku wskazuje 10.02.002, przyczyną może być niezgodność z poziomem zgodności bazy. W przypadku SQL Server administrator może odczytać podstawowe informacje za pomocą prostego zapytania diagnostycznego, np. SELECT name, compatibility_level FROM sys.databases WHERE name = 'PlatnikDB’;. Sam wynik nie przesądza jeszcze o źródle usterki, ale pozwala stwierdzić, czy środowisko SQL jest w ogóle widoczne dla programu.

Jak przeprowadzić diagnozę krok po kroku?

Czynności diagnostyczne wykonuj pojedynczo, a po każdej z nich sprawdzaj, czy objaw się zmienił. Równoczesne stosowanie kilku metod utrudnia wskazanie rzeczywistej przyczyny. Oto optymalna kolejność działań, którą możesz potraktować jak procedurę obowiązującą w Twoim środowisku.

• Zabezpiecz bazę i zapisz treść komunikatu błędu.
• Potwierdź, że uruchamiasz właściwą wersję Płatnika pobraną z serwisu ZUS.
• Uruchom program jako administrator Windows.
• Sprawdź, czy baza nie jest otwarta przez innego użytkownika – szczególnie przy pracy wielostanowiskowej.
• W przypadku SQL Server zweryfikuj, czy usługa SQL Server jest aktywna i czy nazwa instancji pozostała niezmieniona.
• Przy bazie Access upewnij się, że plik fizyczny istnieje w tym samym miejscu co wcześniej i nie został przeniesiony.
• Uruchom ponownie aktualizację komponentów i słowników z oficjalnego źródła – często to jedyny brakujący krok.

Kiedy podejrzewać problem z uprawnieniami?

W wielu środowiskach błąd ten pojawia się po zalogowaniu na konto bez pełnych praw administracyjnych. Dotyczy to zwłaszcza konwersji bazy, która wymaga modyfikacji struktury tabel. Jeżeli program działał prawidłowo na koncie administratora, a na profilu użytkownika wyświetla omawiany komunikat, prawdopodobnie niezbędne będzie ponowne uruchomienie go z poziomu administratora Windows lub sprawdzenie dostępu w SQL Server.

W przypadku baz SQL, uprawnienia warto zweryfikować poleceniem: 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’;. Jeśli okaże się, że konto nie posiada odpowiednich praw, administrator może nadać je jawnie, na przykład przez przypisanie roli db_owner: ALTER ROLE db_owner ADD MEMBER platnik_user;. Operację taką wykonuj tylko po potwierdzeniu, że dotyczy ona właściwej bazy i tylko po wcześniejszym backupie.

Jak naprawić błąd przy użyciu narzędzia P2StartFix?

W wielu wątkach na forum dyskusyjnym pojawia się jedno sprawdzone rozwiązanie – wykorzystanie aplikacji P2StartFix. To lekkie narzędzie, które resetuje datę ostatniej aktualizacji w rejestrze i wymusza ponowne pobranie kompletnych pakietów. Można je pobrać bezpośrednio z dystrybucji ZUS i uruchomić przy zamkniętym Płatniku.

Po zastosowaniu narzędzia wielu administratorów zaobserwowało, że po restarcie program zaczyna długo pobierać pliki – czasem nawet przez kilkanaście minut. To pozytywny sygnał, oznaczający, że metryka oraz komponenty zostały wczytane od nowa. Należy wtedy uzbroić się w cierpliwość i nie przerywać procesu.

Co zrobić, gdy P2StartFix nie pomaga?

Jeśli po uruchomieniu poprawki komunikat nadal się pojawia, można ręcznie wyczyścić wpis w rejestrze. W edytorze regedit przejdź do gałęzi HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Asseco Poland SA\Płatnik\10.02.002\Parametry (dla systemów 64-bitowych) i usuń zawartość wartości DataPobraniaPakiety. Po zapisaniu zmiany uruchom Płatnika – powinna rozpocząć się automatyczna aktualizacja. Potem wystarczy połączyć się z dotychczasową bazą.

W skrajnych przypadkach, gdy baza zawiera błędy strukturalne, konieczne jest utworzenie nowej testowej bazy Access, założenie fikcyjnego płatnika i przeprowadzenie aktualizacji w trybie offline. Po pomyślnym zakończeniu można przełączyć się na rzeczywistą bazę, którą program powinien już rozpoznać. Tę metodę szczegółowo opisywano w wątkach użytkowników i choć wydaje się złożona, często kończy się powodzeniem.

Kiedy ręczna ingerencja w SQL jest uzasadniona?

Ręczna zmiana poziomu zgodności bazy to czynność, którą wykonuje się dopiero po wyczerpaniu wszystkich innych kroków i wyłącznie na kopii zapasowej. Jeśli administrator SQL po analizie stwierdzi, że wersja silnika nie odpowiada oczekiwaniom Płatnika, może zastosować polecenie ALTER DATABASE PlatnikDB SET COMPATIBILITY_LEVEL = 150;. Wcześniej jednak ma obowiązek zapisać powód zmiany i dysponować aktualnym plikiem .bak.

Wszelkie modyfikacje ręczne – niezależnie od tego, czy dotyczą poziomu zgodności, tabel, użytkowników czy plików danych – są zabronione bez pełnego udokumentowania. Dotyczy to szczególnie środowisk, gdzie baza zawiera rzeczywiste dane płatnika i ubezpieczonych. W razie wątpliwości lepiej skorzystać z kopii i wykonać polecenia odtwarzania, np. RESTORE DATABASE PlatnikDB FROM DISK = 'C:\backup\PlatnikDB.bak’;.

Jak uniknąć tego błędu w przyszłości?

Z doświadczeń użytkowników wynika, że wiele kłopotów można wyeliminować, pamiętając o kilku podstawowych zasadach. Przede wszystkim przed każdą aktualizacją sprawdź, czy żaden inny użytkownik nie ma otwartej bazy – dotyczy to zwłaszcza instalacji wielostanowiskowych. Dobrą praktyką jest też uruchamianie Płatnika jako administrator Windows za każdym razem, gdy pobierane są nowe składniki.

Regularnie wykonuj kopię zapasową i zapisuj wersję programu oraz numer metryki. W przypadku środowisk SQL Server warto mieć pod ręką zapytanie diagnostyczne sprawdzające poziom zgodności oraz uprawnienia kont. Dzięki temu przy kolejnym komunikacie o nierozpoznanej bazie będziesz mógł od razu ustalić, czy zmieniły się elementy, na które nie masz wpływu – na przykład certyfikat ZUS, którego zmiany mogą zbiegać się z aktualizacją metryki.