Płatnik po metryce 334: Access violation i błąd kolumny HASLO. Co pomogło

W piątek 30 października wieczorem ZUS wypuścił metrykę 334 do Płatnika 10.02.002 (pit.pl). Po aktualizacji trzeba przekonwertować bazę i przejść nowy kreator klucza szyfrowania.

U klienta z bazą Płatnika na SQL Server skończyło się na dwóch błędach, jeden po drugim. Poniżej, co pomogło. Po obu poprawkach konwersja przeszła do końca.

Dotyczy baz na SQL Server. Przy bazie Access problemy są inne.

Błąd 1: „is dependent on column 'HASLO'”

Pierwszy wyskoczył w kreatorze połączenia z bazą, w trakcie konwersji:

To komunikat z SQL Servera. Metryka 334 zapisuje hasła użytkowników Płatnika inaczej, więc konwersja chce zmienić kolumnę HASLO w tabeli HISTORIA. U klienta ta kolumna siedziała w kluczu głównym i SQL Server nie pozwolił jej ruszyć.

Z tego, co piszą na nubeit.pl, łapią to głównie bazy przeniesione kiedyś na SQL Server inaczej niż konwerterem Płatnika, np. ze starej bazy Access.

Co pomogło: narzędzie z nubeit.pl

Pomogło narzędzie z nubeit.pl, u klienta zadziałało bez kłopotów. Sprawdza, czy baza jest zbudowana nietypowo, i jeśli tak, przenosi dane do bazy o poprawnej strukturze. Potem konwersja w Płatniku idzie normalnie.

1. Nie ponawiaj konwersji w Płatniku

   Autorzy narzędzia ostrzegają, że każda kolejna próba psuje bazę bardziej.

2. Zrób kopię bazy i zamknij Płatnika

   Kopia zapasowa bazy, potem zamknij Płatnika na wszystkich stanowiskach.

3. Uruchom narzędzie na serwerze SQL

   Na komputerze, na którym działa SQL Server z bazą Płatnika, a nie na zwykłym stanowisku.

4. Podaj konto z rolą sysadmin

   Gdy narzędzie zapyta o login SQL, podaj konto z rolą sysadmin, np. sa.

Instrukcja i plik do pobrania są na nubeit.pl. To nie jest narzędzie od ZUS.

Błąd 2: „Access violation at address 00000000”

Przy następnej próbie Płatnik stawał na komunikacie:

Ani do ustawień, ani do konwersji. Adres 00000000 znaczy tyle, że program sięgnął po coś, czego nie ma. Po metryce 334 zgłasza to sporo biur ze wspólną bazą SQL: kreator klucza szyfrowania kończy się dobrze, a błąd wyskakuje przy logowaniu jako ADMINISTRATOR. Na forach piszą, że restart, uruchomienie jako administrator ani P2StartFix2.exe nie pomagają.

Przyczyna: konto sa z pustym hasłem

Płatnik łączył się z SQL Serverem kontem sa bez hasła. Widać to w rejestrze, w kluczu:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Asseco Poland SA\Płatnik\10.02.002\Baza

User ID ma wartość sa, a Password jest puste. Na Windows 32-bitowym ścieżka jest ta sama, tylko bez WOW6432Node.

Na forum Płatnika ktoś wypisał dwa warunki dla baz SQL po metryce 334: połączenie przez sa albo inne konto z rolą sysadmin, a hasło nie może być puste (nie musi mieć 12 znaków). Nowy Płatnik po prostu nie radzi sobie z pustym hasłem.

U klienta baza Płatnika stała na serwerze SQL od programów InsERT GT (instancja INSERTGT). Zanim ustawisz hasło na sa w samym SQL Serverze, sprawdź, czy nie łączą się nim inne programy. Odetniesz je od bazy.

Co pomogło: niepuste hasło w rejestrze

Wystarczyło wpisać w rejestrze jakiekolwiek hasło, byle nie puste. Konta sa w SQL Serverze nie ruszałem, więc programy InsERT działały dalej jak wcześniej.

1. Zamknij Płatnika wszędzie

   Na wszystkich komputerach, które korzystają z tej bazy.

2. Otwórz Edytor rejestru jako administrator

   Start, wpisz regedit, prawy przycisk, Uruchom jako administrator. Bez tego zmiany w HKEY_LOCAL_MACHINE się nie zapiszą.

3. Wyeksportuj klucz Baza

   Przejdź do klucza Baza (ścieżka wyżej), kliknij go prawym przyciskiem i wybierz Eksportuj. Z pliku .reg w razie problemów przywrócisz ustawienia dwuklikiem.

4. Wpisz hasło w Password

   Kliknij dwukrotnie wartość Password i wpisz dowolne hasło. Bezpieczniej użyć samych liter i cyfr, bo znaki ;, = i cudzysłowy mogą zepsuć dane połączenia.

5. Przejdź przez kreatory

   Uruchom Płatnika, zaloguj się jako ADMINISTRATOR i przejdź przez kreatory: klucz szyfrowania, klucz odzyskiwania dostępu i konwersję bazy.

Access violation zniknął, a konwersja przeszła do końca.

Jeśli to nie pomoże

Załóż Płatnikowi osobne konto SQL, z rolą sysadmin i normalnym hasłem. Na komputerze z serwerem SQL otwórz wiersz poleceń jako administrator i połącz się kontem sa (przy pytaniu o hasło sam Enter). Nazwę serwera i instancji weź z wartości Data Source w rejestrze:

sqlcmd -S NAZWAKOMPUTERA\INSTANCJA -U sa
CREATE LOGIN platnik_admin WITH PASSWORD = 'TwojeHaslo2026Platnik';
ALTER SERVER ROLE sysadmin ADD MEMBER platnik_admin;
GO

Na starszym SQL Server (2008 R2 i wcześniej) zamiast ALTER SERVER ROLE użyj EXEC sp_addsrvrolemember 'platnik_admin', 'sysadmin';. Potem w kluczu Baza wpisz w User ID nowy login, a w Password jego hasło. Jeśli Płatnik nie połączy się w ten sposób, powinien otworzyć kreator połączenia, w którym podasz te same dane.

Przy błędzie HASLO zamiast narzędzia z nubeit.pl można spróbować darmowego M334 od InnerSoft (platnikmanager.pl). Sam go nie testowałem. To też nie jest narzędzie od ZUS, więc najpierw pełna kopia bazy.

Zostaje jeszcze infolinia ZUS: 22 560 16 00. Podaj treść obu komunikatów i powiedz, że baza stoi na SQL Server.

Po naprawie

• Zrób kopię bazy już po konwersji. Przy następnej awarii nie zaczynasz od zera.
• Zapisz klucz odzyskiwania dostępu gdzieś poza tym komputerem. Bez niego zapomniane hasło ADMINISTRATORA to duży kłopot.
• Na pozostałych stanowiskach konwersji nie powtarzasz, baza jest wspólna. Jeśli tam też wyskoczy Access violation, pomaga ta sama zmiana w rejestrze.
• Konto sa bez hasła to otwarte drzwi: każdy w sieci może przejąć cały serwer SQL. Hasło warto ustawić, ale razem z poprawieniem połączeń we wszystkich programach, które z niego korzystają.

Płatnik nie wysyła do ZUS? Zobacz też błąd TSL w Płatniku. A jeśli nie masz czasu się w to bawić, napisz albo zadzwoń: 737 458 879, naprawię to u Ciebie.

Źródła: pit.pl, instrukcja ZUS: zmiany w Płatniku wprowadzane metryką 334 (PDF), nubeit.pl, forumplatnika.pl: narzędzie diagnostyczno-naprawcze, forumplatnika.pl: Access violation.