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

Komunikat ten oznacza fundamentalną niezgodność pomiędzy strukturą bazy danych a uruchomioną wersją programu. Aplikacja nie jest w stanie bezpiecznie odczytać metadanych, co uniemożliwia dalszą pracę. Poznaj szczegółową metodę diagnostyki i naprawy tego problemu, opartą na oficjalnych procedurach.

Czym jest błąd nierozpoznania wersji bazy i dlaczego jest krytyczny?

Wbrew pozorom nie jest to zwykły błąd startowy, który można zignorować. Dotyczy on bezpośrednio integralności miejsca, w którym przechowywane są wszystkie dokumenty zgłoszeniowe i rozliczeniowe oraz konfiguracja środowiska pracy. Przyczyną takiego stanu rzeczy może być kilka zdarzeń – najczęściej występuje on po nieukończonej lub przerwanej procedurze aktualizacyjnej, po fizycznym przeniesieniu plików bazy na inny dysk czy serwer, po awarii instancji SQL Server lub po modyfikacji uprawnień dostępu w systemie operacyjnym. Zdarza się również, że błąd pojawia się w momencie, gdy uruchomimy starszą wersję programu, która próbuje nawiązać połączenie z bazą zmodyfikowaną już przez nowsze wydanie aplikacji.

Status tego alertu jest o tyle poważny, że wszelkie próby naprawy podejmowane bez odpowiedniej wiedzy mogą doprowadzić do nieodwracalnego uszkodzenia danych. Dlatego priorytetem jest nie szybkie usunięcie komunikatu, ale zachowanie danych płatnika i ubezpieczonych. Przed rozpoczęciem jakichkolwiek działań trzeba bezwzględnie upewnić się, że istnieje aktualna, sprawna i odtworzeniowa kopia bazy.

Jak zabezpieczyć dane przed przystąpieniem do naprawy?

To absolutny fundament dalszych działań. Jeżeli nie posiadasz aktualnego backupu, musisz go wykonać teraz, zanim klikniesz cokolwiek innego. Metoda tworzenia kopii różni się w zależności od używanego silnika bazy danych. W przypadku baz MS Access należy fizycznie skopiować właściwy plik z rozszerzeniem .mdb, a nie tylko katalog samego programu. Dla baz uruchomionych na Microsoft SQL Server kopia zapasowa powinna być wykonana przez administratora SQL za pomocą dedykowanych narzędzi, takich jak Management Studio.

Podczas tworzenia kopii warto zanotować kilka informacji, które będą niezbędne na etapie odtwarzania danych lub kontaktu ze wsparciem technicznym. Powinieneś zapisać dokładną datę i godzinę wykonania backupu, fizyczną lokalizację bazy, jej typ (Access lub SQL Server), nazwę instancji SQL, wersję programu Płatnik generującą błąd oraz pełną, dosłowną treść komunikatu. Te szczegóły są pomocne przy identyfikacji rozbieżności.

Bez sprawdzonej kopii zapasowej nie wykonuj reinstalacji, ręcznych zmian w tabelach za pomocą SSMS, usuwania plików fizycznych ani przenoszenia bazy. Takie działania mogą trwale utrudnić odtworzenie środowiska.

Analiza wersji programu i przyczyn niezgodności

Aktualna, oficjalnie dystrybuowana wersja programu to Płatnik 10.02.002. W komunikacie technicznym z 23 stycznia 2026 roku Zakład Ubezpieczeń Społecznych poinformował o wdrożeniu dla niej metryki 320. Ta metryka jest pobierana automatycznie podczas procesu aktualizacji, jednak wiele czynników może ten proces zakłócić. Jeśli problem wystąpił tuż po próbie aktualizacji, należy zweryfikować kilka kwestii związanych z integralnością plików.

W pierwszej kolejności potwierdź, że instalator został pobrany wyłącznie z oficjalnej strony ZUS w sekcji pobierania. Sprawdź, czy proces pobierania aktualizacji i wgrywania komponentów nie został przerwany, a program miał pełną możliwość pobrania wszystkich niezbędnych składników. Upewnij się też, że w momencie aktualizacji baza danych nie była używana przez żadnego innego użytkownika. Inny scenariusz zakłada, że problemem jest nie sama baza, a uruchomienie przestarzałego skrótu prowadzącego do starej instalacji programu, podczas gdy nowa wersja znajduje się w innej lokalizacji na dysku.

Jak środowisko sieciowe i SQL wpływają na ten błąd?

Gdy infrastruktura opiera się na Microsoft SQL Server, diagnostyka wymaga szerszego spojrzenia na konfigurację sieciową i uprawnienia. Aby odczytać podstawowe informacje o stanie bazy, można posłużyć się narzędziem SQL Server Management Studio (SSMS). Wykonanie nieszkodliwego zapytania diagnostycznego pomoże administratorowi zorientować się w poziomie środowiska. Przykładowo, aby wyświetlić poziom zgodności bazy o nazwie ‘PlatnikDB’, można użyć polecenia:

SELECT name, compatibility_level FROM sys.databases WHERE name = ‘PlatnikDB’;

Sam numer poziomu zgodności nie jest jeszcze ostatecznym rozstrzygnięciem, ale pozwala określić, czy baza nie została w niekontrolowany sposób podniesiona do wersji, której starszy klient nie obsłuży. Kolejnym ważnym aspektem jest weryfikacja uprawnień. Do diagnozy wymagana jest osoba z uprawnieniami administratora programu, administratora Windows lub administratora SQL Server. Taka osoba musi sprawdzić, czy profil użytkownika w systemie Windows ma uprawnienia do odczytu i zapisu w katalogu programu oraz czy sama instancja SQL jest dostępna z poziomu stacji roboczej.

Należy również upewnić się, że konto używane do autoryzacji przez Płatnika nie zostało zablokowane na poziomie bazy danych. Problematyczne bywają też zmiany wprowadzone po fizycznym przeniesieniu komputera, takie jak zmiana nazwy serwera, na którym działa instancja. Jeśli administrator potwierdzi, że konto powinno mieć pełne prawa do bazy, może jawnie je nadać za pomocą odpowiedniego polecenia.

Aby zweryfikować szczegółowe uprawnienia konkretnego użytkownika, można wykonać zapytanie diagnostyczne: 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’;

Jak przeprowadzić uporządkowaną procedurę naprawczą?

Chaotyczne wykonywanie wielu czynności naraz sprawia, że nigdy nie wiadomo, która z nich zadziałała, a która zaszkodziła. Dlatego należy postępować metodycznie, testując program po każdym pojedynczym kroku. W celu odzyskania sprawności systemu należy wykonać sekwencję działań, którą można rozpocząć od globalnego przeglądu uprawnień, a skończyć na wymuszeniu ponownego pobrania danych.

Listę kontrolną warto rozpocząć od wykonania kopii bazy i zanotowania pełnego komunikatu. Następnie weryfikujemy, czy uruchamiana jest właściwa wersja aplikacji (10.02.002) oraz sprawdzamy oficjalną stronę ZUS w poszukiwaniu nowych komunikatów technicznych, które mogły się pojawić. W praktyce wiele problemów znika po uruchomieniu programu w trybie administratora Windows, ponieważ znosi to część restrykcji dostępu. Jeżeli korzystasz z SQL Server, zweryfikuj, czy usługa SQL Server działa i czy używasz poprawnej nazwy instancji. Przy bazie Access sprawdź, czy plik .mdb fizycznie istnieje i czy nie został przypadkowo przeniesiony w inne miejsce.

Istotne jest też wyeliminowanie możliwości, że ktoś inny blokuje pliki poprzez niezamkniętą sesję. Jeśli wszystkie te weryfikacje nie przyniosą rezultatu, ostatnim punktem jest próba wymuszenia ponownej aktualizacji wraz z komponentami z oficjalnego źródła.

Kiedy i jak ingerować ręcznie w strukturę danych?

Ręczna modyfikacja bazy danych powinna być absolutną ostatecznością i może być wykonana tylko przez wykwalifikowanego administratora baz danych. Nigdy nie wolno zmieniać struktury tabel, poziomu zgodności czy ręcznie dodawać użytkowników bez posiadania możliwości natychmiastowego odtworzenia backupu. Szczególnie dotyczy to poleceń wydawanych na produkcyjnej bazie w środowisku SQL Server Management Studio. Działanie takie jest zarezerwowane dla osoby, która rozumie strukturę środowiska i ma zgodę właściciela danych. Jeśli po głębokiej analizie administrator uzna, że problemem jest wyłącznie poziom zgodności bazy, może użyć polecenia do jego zmiany.

Przykładowa komenda zmienia poziom zgodności na 150: ALTER DATABASE PlatnikDB SET COMPATIBILITY_LEVEL = 150; Jednak nigdy nie jest to pierwszy krok diagnostyki i zawsze musi być poprzedzony pełnym backupem.

W skrajnych przypadkach, gdy baza jest nieodwracalnie uszkodzona, a kopia zapasowa jest sprawna, konieczne może być odtworzenie danych z backupu. Standardowe schematy poleceń do wykonania backupu, a następnie odtworzenia bazy na serwerze SQL wyglądają następująco, choć konkretna ścieżka pliku i nazwa muszą być potwierdzone przez osobę administrującą serwerem:

• BACKUP DATABASE PlatnikDB TO DISK = ‘C:\backup\PlatnikDB.bak’;
• RESTORE DATABASE PlatnikDB FROM DISK = ‘C:\backup\PlatnikDB.bak’;

Jak odbudować środowisko w przypadku niepowodzenia standardowych metod?

Gdy standardowa procedura diagnostyczna zawodzi, a komunikat uparcie wskazuje na niemożność rozpoznania wersji, w ostateczności można przeprowadzić procedurę generowania nowej, czystej bazy oraz ręcznego wgrywania metryki z poziomu pliku. Metoda ta opiera się na odizolowaniu problematycznej konfiguracji i zbudowaniu od nowa elementów odpowiedzialnych za obsługę aktualizacji. Pierwszym krokiem jest całkowite odinstalowanie programu z poziomu Panelu Sterowania, a następnie ręczne usunięcie pozostałości.

Po restarcie systemu należy usunąć lub zmienić nazwy katalogów Asseco w “Program Files” oraz w ukrytym folderze “ProgramData”. Instalujemy program od nowa, ale z krytycznym warunkiem – na etapie wyboru bazy danych należy wskazać wersję MS Access i obowiązkowo zaznaczyć opcję utworzenia nowej, pustej bazy. Zanim uruchomisz program, pobierz i wykonaj narzędzie P2StartFix.exe, które resetuje ustawienia aktualizacji. Podczas pierwszego logowania nie pobieraj żadnych aktualizacji on-line. W tej czystej bazie zakładasz fikcyjnego płatnika, aby móc przejść dalej i uzyskać dostęp do menu narzędzi. Następnie ręcznie wskazujesz ścieżkę do pliku „metryka.xml”, aby zainstalować aktualizację z dysku, przeprowadzasz restart aplikacji, a dopiero na końcu wykonujesz pełną aktualizację online i przełączasz się z powrotem na swoją oryginalną bazę SQL lub Access.