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” sygnalizuje brak zgodności między strukturą bazy a uruchomioną wersją programu, co uniemożliwia bezpieczną pracę. Zanim podejmiesz jakiekolwiek działania, bezwzględnie zabezpiecz kopię zapasową swoich danych – to podstawa uniknięcia ich bezpowrotnej utraty. W dalszej części artykułu opisujemy pełną diagnostykę i sprawdzone ścieżki naprawy.

Co oznacza błąd nierozpoznanej wersji bazy?

Pojawienie się tego alertu to informacja od programu, że nie potrafi on zweryfikować struktury plików danych w kontekście swojej aktualnej funkcjonalności. Taka sytuacja najczęściej występuje po nieukończonej aktualizacji, ręcznym przeniesieniu bazy do innej lokalizacji, awarii serwera SQL lub starcie uprawnień użytkownika. Nie jest to wyłącznie drobna usterka startowa – dotyczy bezpośrednio integralności miejsca, w którym zapisane są dokumenty zgłoszeniowe i cała konfiguracja środowiska.

Zdarza się, że przyczyna leży po stronie nie samej bazy, a użytego skrótu do programu. Uruchomienie starszej wersji Płatnika, która próbuje uzyskać dostęp do plików zmodyfikowanych przez nowsze wydanie, wywoła identyczny komunikat. Z tego powodu diagnostykę zawsze rozpoczyna się od weryfikacji, czy uruchamiana jest właściwa instalacja i czy inni użytkownicy sieciowi nie korzystają z tych samych zasobów.

Bez wykonania aktualnej kopii bezpieczeństwa nie przystępuj do reinstalacji, ręcznego usuwania tabel ani przenoszenia plików. Operacje te mogą nieodwracalnie utrudnić późniejsze odtworzenie danych.

Jak zabezpieczyć dane przed przystąpieniem do naprawy?

Pierwszą i najważniejszą czynnością jest potwierdzenie istnienia pełnej kopii zapasowej. Jeśli jej nie masz, wykonaj ją natychmiast, wykorzystując uprawnienia administratora. Dla środowisk korzystających z Microsoft SQL Server kopia to zadanie administratora bazy, realizowane przez Management Studio lub polecenia T-SQL. W przypadku formatu Access zabezpieczasz właściwy plik z rozszerzeniem .mdb, który często znajduje się poza katalogiem samej aplikacji.

Zanotuj również kontekst awarii – to usprawni późniejszą analizę. Zanotuj dokładną datę i godzinę wykonania kopii, ścieżkę dostępu, typ silnika bazy (Access albo SQL Server) oraz nazwę instancji serwera, jeśli dotyczy. Do tych informacji dopisz wersję programu Płatnik i pełną, niezmienioną treść komunikatu o błędzie.

Jak przeprowadzić diagnostykę krok po kroku?

Postępowanie naprawcze wymaga metodyczności. Losowe wykonywanie kilku poprawek jednocześnie zaciera obraz sytuacji i wydłuża czas przestoju. Poniższą sekwencję najlepiej realizować punkt po punkcie, za każdym razem sprawdzając, czy symptom ustąpił.

Na początku zweryfikuj integralność źródła instalacji:

• czy program pobrano wyłącznie z oficjalnej strony Zakładu Ubezpieczeń Społecznych,
• czy proces aktualizacji przebiegł bez przerwania i pobrał aktualną metrykę,
• czy na czas wgrywania komponentów żaden inny użytkownik nie miał aktywnej sesji na bazie.

Weryfikacja środowiska i uprawnień

Do pełnej diagnozy niezbędny jest profil użytkownika z uprawnieniami administracyjnymi – może to być administrator programu, systemu Windows, SQL Server lub właściciel środowiska w firmie. Potwierdź, że konto Windows ma dostęp do katalogu instalacyjnego i plików bazy, a aplikacja jest uruchamiana na właściwym profilu. Po przeniesieniu komputera do innej domeny lub zmianie konfiguracji sieciowej, nazwa instancji serwera mogła ulec modyfikacji, co bezpośrednio zerwie połączenie.

Jeśli nie dysponujesz odpowiednimi uprawnieniami, poprzestań na zebraniu danych o stanie systemu. Próby siłowego naprawiania bez dostępu administracyjnego prowadzą często do chaotycznych modyfikacji, których potem nikt nie potrafi odtworzyć. Administrator SQL może wesprzeć diagnostykę nieszkodliwym zapytaniem w SSMS, sprawdzającym poziom zgodności bazy: SELECT name, compatibility_level FROM sys.databases WHERE name = 'PlatnikDB’;. Wartość tego parametru nie przesądza jeszcze o przyczynie, ale dostarcza cennej wskazówki o stanie środowiska serwerowego.

Analiza połączenia z serwerem SQL

W instalacjach wielostanowiskowych problem może dotyczyć tylko wybranych stacji roboczych, podczas gdy serwer i reszta klientów pracują bez zarzutu. Należy wtedy ustalić, czy na niedziałającym komputerze usługa SQL Server jest osiągalna. Sprawdza się to poprzez ping na nazwę serwera i test połączenia z odpowiednią instancją. Częstą przyczyną bywa blokada przez zaporę sieciową lub program antywirusowy, które po aktualizacji Płatnika przestają ufać nowym plikom wykonywalnym.

Diagnostykę uzupełnia analiza uprawnień konta używanego przez Płatnika do logowania się do bazy. Odczytanie ról i pozwoleń realizuje się zapytaniem w Management Studio, filtrując po nazwie użytkownika. Jeżeli z jakiegoś powodu konto utraciło niezbędne prawa, administrator nadaje je ponownie, dodając je do roli db_owner wyłącznie dla właściwej bazy programu.

Wszystkie ręczne ingerencje w strukturę bazy – modyfikacja poziomu zgodności, zmiana tabel, kont czy plików – zostaw na koniec i tylko dla osoby, która rozumie całą infrastrukturę, wykonała backup i dokumentuje każdą operację.

Jak naprawić nierozpoznaną bazę?

Gdy standardowa diagnostyka nie przynosi rezultatu, konieczne staje się odtworzenie poprawnej ścieżki aktualności komponentów. ZUS w komunikacie technicznym ze stycznia 2026 roku poinformował o wdrożeniu metryki 320 dla wersji 10.02.002, która jest pobierana automatycznie przy sprawnej instalacji. Jeżeli mechanizm automatyczny zawiedzie, należy wymusić ponowne pobranie danych słownikowych i składników programu.

Najczęściej skuteczną interwencją okazuje się wyczyszczenie wartości klucza rejestru odpowiedzialnego za datę ostatniego pobrania pakietów. W gałęzi HKEY_LOCAL_MACHINE\SOFTWARE\Asseco Poland SA\Płatnik\10.02.002\Parametry (dla systemów 32-bit) lub analogicznej w węźle WOW6432Node (dla 64-bit) kasuje się zawartość wpisu „DataPobraniaPakiety”. Po ponownym uruchomieniu aplikacji z uprawnieniami administratora systemu Windows, program rozpocznie wymuszony proces pobierania wszystkich brakujących plików. Trwa on niekiedy kilkadziesiąt minut, w trakcie których nie wolno przerywać transmisji danych.

Czyszczenie środowiska i ponowna instalacja

Jeżeli modyfikacja rejestru nie pomaga, stosuje się pełną reinstalację po uprzednim, głębokim oczyszczeniu śladów poprzedniej wersji. Procedurę rozpoczyna się od standardowej deinstalacji przez Panel sterowania oraz usunięciu wszystkich dodatkowych komponentów: środowiska uruchomieniowego WRF, WRFKL i WRFSL. Następnie po restarcie komputera, ręcznie kasuje się pozostałe katalogi programu w C:\Program Files (x86)\Asseco Poland SA oraz ukryty folder danych aplikacji w C:\ProgramData\Asseco Poland SA.

Finalnie usuwa się wpisy rejestru Asseco Poland SA w gałęziach oprogramowania. Dopiero po tych krokach pobiera się najświeższy plik instalacyjny z oficjalnej witryny ZUS-u i – przy wyłączonym antywirusie – przeprowadza czystą instalację z poziomu konta administracyjnego. W trakcie konfiguracji wybiera się opcję utworzenia nowej, tymczasowej bazy Access i zakłada fikcyjnego płatnika, by program mógł przeprowadzić pełną sekwencję aktualizacji słowników i metryk. Dopiero po zakończeniu wszystkich aktualizacji w tym środowisku testowym, przełącza się kontekst na właściwą – oryginalną bazę SQL lub Access.

Konwersja struktury po udanej aktualizacji

W wielu przypadkach po pomyślnym ściągnięciu łatek i ponownym nawiązaniu połączenia, kreator programu zgłosi konieczność konwersji bazy danych. To sygnał, że pliki miały starą strukturę, a obecna wersja oprogramowania rozpoznaje je jako wymagające dostosowania. Przed kliknięciem „Dalej” upewnij się, że wszyscy pozostali użytkownicy sieciowi wyłączyli swoje sesje Płatnika – konwersja wymaga wyłącznego dostępu do bazy.

Program automatycznie tworzy kopię bezpieczeństwa przed zmianą struktury. Po jej zaakceptowaniu i zakończeniu procesu, baza jest ustawiana jako aktywna, a dostęp do danych zostaje przywrócony. W modelu wielostanowiskowym operację tę wykonuje się raz na serwerze, po czym klienci łączą się już z przekonwertowaną instancją.