Migrację Płatnika ZUS z bazą SQL Server robi się przez archiwum płatnika i funkcję „Odtwórz z archiwum”, a nie przez kopiowanie plików programu. Przenosiliśmy Płatnika klienta na nową maszynę wirtualną i dostaliśmy na start jedną kopię bazy w pliku .bak. Opisujemy, jak sprawdziliśmy jej zawartość bez dotykania produkcji, której ścieżki z dokumentacji ZUS odpadają na SQL Server 2022 i jak przenieść dane na starszą wersję SQL Servera, gdy kopii .bak nie da się tam przywrócić.
Jak przenieść Płatnika na inny komputer lub serwer?
Podręcznik administratora Płatnika (wersja 7.3) opisuje przenoszenie płatnika między bazami w rozdziale 5.1.3. Ścieżka w programie: Rejestr płatników, Narzędzia, Odtwórz z archiwum. Do wyboru są dwa źródła:
- z domyślnego archiwum, czyli archiwum utworzonego przy bazie roboczej,
- z innej bazy roboczej, SQL albo Access, z której program pokazuje listę płatników do odtworzenia.
Według dokumentacji archiwizacja do drugiej bazy to oficjalny sposób przenoszenia płatnika. Rozdział 5.1.1 dodaje ograniczenie, o którym łatwo zapomnieć: domyślne archiwum musi być tego samego rodzaju co baza robocza i działa wyłącznie z bazą, z której powstało, więc po instalacji programu na czystym serwerze z nową bazą zostaje tylko druga opcja.
Co jest w pliku .bak Płatnika?
To trzeba sprawdzić, zanim zaplanuje się przeniesienie. Kopię przywróciliśmy w lokalnym kontenerze Docker z MSSQL 2022, bez instalowania czegokolwiek u klienta. Nagłówek pokazał wersję 16.0, czyli 2022, i sortowanie Polish_CI_AS.
Po tabelach od razu było widać, że to nie baza robocza, tylko archiwum płatnika utworzone przez Płatnika. Zawierało jednego płatnika, 31 ubezpieczonych, 574 dokumenty i 65 zestawów, a ostatnia wysyłka dotyczyła deklaracji DRA za sierpień 2026 r. Ta różnica zmienia cały plan, bo archiwum nie podłącza się do programu jak zwykłej bazy, tylko odtwarza się z niego płatnika.
Tabela użytkowników programu była pusta. To dobra wiadomość, bo po przeniesieniu nie trzeba odzyskiwać hasła do Płatnika ani prosić o nie osoby, która prowadzi rozliczenia.
Czy Płatnik działa na SQL Server 2022?
Wymagania techniczne Płatnika kończą listę obsługiwanych serwerów bazy danych na wersji 2017. W praktyce klient od dłuższego czasu pracował na wersji 2022 i program działał bez zastrzeżeń. Kłopot zaczyna się dopiero przy migracji między rodzajami baz.
Rozdział 5.5.7 dokumentacji mówi, że migracja Access do SQL i z powrotem wymaga 32-bitowego serwera, bo korzysta z silnika MS JET. Edycja 2022 jest wyłącznie 64-bitowa, więc tam ta funkcja nie zadziała. Na forum dla użytkowników Płatnika można znaleźć radę, żeby przywrócić .bak w SQL, a potem zmigrować płatnika do pliku .mdb. Przy wersji x64 nie da się na tym polegać.
Którą ścieżkę migracji Płatnika wybrać?
| Wariant | Kiedy działa | Ryzyko |
|---|---|---|
| Odtwórz z domyślnego archiwum | Tylko z tą samą bazą roboczą, przy której powstało archiwum | Na docelowym serwerze nie ma tej bazy |
| Migracja do Access (.mdb), potem odtworzenie | Gdy serwer bazy jest 32-bitowy | Na edycji 2022 x64 nie zadziała |
| SQL Express 2022 na docelowej VM, przywrócenie .bak, odtworzenie płatnika z drugiej bazy | Gdy na VM można zainstalować wersję 2022 | Wymaga uprawnień administratora |
| Eksport schematu i danych na starszy serwer | Gdy docelowa wersja SQL jest starsza niż źródłowa | Kodowanie polskich znaków na etapie pośrednim |
Wybraliśmy trzeci wariant jako roboczy: SQL Express 2022 na nowej maszynie wirtualnej, przywrócenie archiwum jako osobnej bazy i odtworzenie płatnika z innej bazy roboczej. Zanim go uruchomimy, sprawdzamy na maszynie, czy jest już tam serwer bazy danych i czy mamy uprawnienia administratora. Służy do tego skrypt rozpoznania, który tylko czyta: system, instalację Płatnika, SQL Server i sieć.
Jak przenieść bazę Płatnika na starszy SQL Server?
Microsoft nie pozwala przywrócić kopii .bak zrobionej w nowszej wersji serwera. Jeśli docelowe środowisko ma starszą edycję, strukturę i dane przenosi się osobno. W ten sposób przygotowaliśmy trzy kolejne archiwa płatników, które miały przejść przez pośredni serwer w wersji 2014, a całą pracę wykonaliśmy lokalnie, bez dotykania maszyny klienta i bez wysyłania danych gdziekolwiek poza nasz komputer.
- Każde archiwum przywróciliśmy w tym samym lokalnym kontenerze.
- Schemat wygenerowaliśmy narzędziem mssql-scripter z docelową wersją 2014: tabele, klucze i ograniczenia, bez tworzenia bazy, ścieżek plików i osobnych indeksów.
- Dane wyeksportowaliśmy narzędziem bcp w formacie natywnym z Unicode, tabela po tabeli, bo przy kilkudziesięciu tabelach na archiwum łatwiej wtedy wskazać, która z nich nie przeszła.
- Do paczek dołączyliśmy listy tabel i liczniki wierszy.
Skrypt schematu zaczyna się od nazwy bazy docelowej wstawionej jako zmienna do podmiany. Dzięki temu nie tworzy bazy sam i nie nadpisze niczego przez pomyłkę.
Jak sprawdzić, że eksport bazy Płatnika jest kompletny?
Bez weryfikacji eksport to tylko nadzieja. Sprawdziliśmy trzy rzeczy:
- Wiersze. 139 tabel z danymi, łącznie 2735 wierszy. Liczba wierszy z każdego eksportu bcp zgadzała się z COUNT_BIG w bazie źródłowej, a powtórne liczenie dało ten sam wynik.
- Pliki. Sumy SHA-256 po skopiowaniu plików z kontenera były zgodne z oryginałem.
- Schemat. Skrypty wykonaliśmy w tymczasowej bazie testowej. Powstało 128 tabel, 3066 kolumn, 122 klucze główne, jedno ograniczenie UNIQUE i 8 wartości domyślnych, po czym bazy testowe usunęliśmy.
Wynik tej części to „verified” dla przygotowania lokalnego. Importu na maszynie klienta w tym etapie nie robiliśmy, bo zlecenie obejmowało tylko przygotowanie paczek.
Co z polskimi znakami przy migracji Płatnika?
Tu zostaje otwarte ryzyko i piszemy o nim wprost. Polskie znaki mogą ulec uszkodzeniu na pośrednim serwerze w wersji 2014, także przy natywnym formacie bcp. Lokalny test schematu tego nie wykryje, bo uruchamialiśmy go na wersji 2022.
Po imporcie na serwerze pośrednim trzeba więc porównać nazwiska, nazwy płatników i adresy z diakrytykami z bazą źródłową. Dopiero po tym porównaniu można odtwarzać płatnika w programie. Gdyby znaki się psuły, lepiej to wykryć na kilku rekordach w bazie testowej niż na deklaracji wysłanej do ZUS.
Jak przygotować się do migracji Płatnika?
- Poproś o świeżą kopię bazy i sprawdź na niej, czy to baza robocza, czy archiwum.
- Ustal wersję serwera bazy danych na starym i docelowym komputerze oraz to, czy jest 32-, czy 64-bitowa, bo od tego zależy, które funkcje migracji w ogóle zadziałają.
- Sprawdź tabelę użytkowników programu, żeby wiedzieć, czy po przeniesieniu potrzebne będzie hasło.
- Zanotuj datę ostatniej wysyłki, żeby po migracji porównać, czy widać ten sam stan.
- Zaplanuj przeniesienie między terminami składania deklaracji, a nie tuż przed nimi.
- Hasła do bazy trzymaj w menedżerze haseł albo pliku konfiguracyjnym poza repozytorium, nie w notatkach.
Jak przenosimy Płatnika i inne programy w ASAPDevs?
Każdą kopię najpierw otwieramy w izolowanym kontenerze, a dopiero kiedy wiemy, co w niej jest, planujemy zmiany u klienta. Skrypty, które uruchamiamy u klienta, w pierwszym kroku tylko czytają, a każdy etap kończymy jawnym werdyktem: co jest sprawdzone, a co nie. Migracje programów księgowych i kadrowych robimy w ramach przenoszenia serwerów oraz stałej obsługi IT firm.
Zmieniasz serwer albo komputer, na którym działa Płatnik? Zacznijmy od kopii bazy, a nie od instalacji. Zobacz, jak przenosimy serwery i bazy danych →
