Replikator DBF2SQL przenosi tabele z plików DBF do Microsoft SQL Server, zmienia kodowanie na Windows 1250 i zapisuje wynik w dwóch plikach dziennika.
Format DBF przez lata obsługiwał programy działające w środowisku DOS i Windows. Każda tabela leży w osobnym pliku, a aplikacja czyta go bezpośrednio z dysku. Gdy przybywa rekordów i użytkowników, taki układ zwalnia pracę i utrudnia rozbudowę programu. Trudno też podłączyć stary system do nowych aplikacji. Dlatego firmy sięgają po migrację do baz danych SQL. Replikator DBF2SQL pozwala ją przeprowadzić bez ręcznego przepisywania tabel.
Czy warto migrować z DBF do SQL?
Serwer SQL daje mechanizmy, których pliki DBF nie mają. Transakcja zapisuje dokument razem z pozycjami w całości albo wcale. Indeksy utrzymywane przez serwer skracają wyszukiwanie w dużych tabelach, bo zapytanie nie czyta każdego wiersza po kolei. Uprawnienia przydziela się osobno każdemu użytkownikowi bazy. Różnicę widać najlepiej wtedy, gdy z jednej bazy korzysta wiele osób naraz.
| Obszar | Pliki DBF | Baza SQL Server |
|---|---|---|
| Układ danych | Każda tabela leży w osobnym pliku na dysku | Tabele znajdują się w bazie prowadzonej przez serwer |
| Zapis dokumentu | Tabele zapisują się osobno, jedna po drugiej | Transakcja zapisuje dokument w całości albo wcale |
| Wyszukiwanie | Indeksy leżą w osobnych plikach obok tabeli | Indeksy utrzymuje serwer |
| Uprawnienia | Dostęp do danych wynika z dostępu do pliku | Uprawnienia przydziela się użytkownikom bazy |
Migracja wymaga czasu na opisanie struktury tabel i sprawdzenie przeniesionych danych. Ten nakład zwraca się w codziennej pracy, bo utrzymanie bazy na serwerze jest prostsze niż pilnowanie osobnych plików DBF. Maleją też koszty utrzymania systemu.
Programy SoftwareStudio Group Sp. z o.o. korzystają z technologii Microsoft, więc serwer musi spełniać wymagania i zalecenia producenta dla aplikacji IIS Server i SQL Server. Ogólny opis platformy podaje dokumentacja SQL Server w Microsoft Learn. Wiele programów o bogatej funkcjonalności nadal pracuje w środowisku DOS lub Windows na bazach DBF. Z czasem funkcji przybywa, a razem z nimi rośnie rozmiar baz.
Do tego dochodzą aplikacje internetowe. Stawiają wyższe wymagania bezpieczeństwa i zakładają bazę typu SQL, której same pliki DBF nie zastąpią.
Replikator.net w wersji DBF2SQL
Do czego służy Replikator DBF2SQL?
Replikator DBF2SQL napisała firma SoftwareStudio. Program synchronizuje dane między plikami DBF a Microsoft SQL Server. Podczas przegrywania sam zamienia kodowanie polskich znaków na Windows 1250. Odciąża działy IT w firmach, które utrzymują starsze systemy bazodanowe.
Użytkownik z uprawnieniami administratora może w dowolnym momencie uruchomić synchronizację wybranych tabel. Replikator sprawdza się najlepiej tam, gdzie obok siebie działają programy DOS i Windows zapisujące dane w DBF. Wymaga tych samych warunków co każda aplikacja na IIS Server i SQL Server. Zastępuje ręczne przenoszenie danych między formatami, w którym łatwo o literówkę albo pominiętą tabelę.
W trakcie pracy okno informacyjne pokazuje postęp replikacji. Wynik sprawdza się potem w plikach dziennika, opisanych niżej. Cztery cechy narzędzia decydują o tym, jak przebiega przenoszenie tabeli:
- Odczyt struktury. Aplikacja analizuje strukturę tabeli źródłowej i na jej podstawie buduje zapytanie INSERT, które dopisuje rekordy do bazy.
- Kodowanie znaków. Polskie znaki z plików DBF zmieniają się automatycznie na Windows 1250.
- Nazwy zastrzeżone. Najbardziej znane nazwy kolumn, na przykład USER i UPDATE, są podmieniane automatycznie. Słów zastrzeżonych T-SQL nie można użyć jako nazwy kolumny bez nawiasów kwadratowych.
- Baza docelowa. Replikacja obejmuje dane z siedmiu najpopularniejszych systemów bazodanowych, a docelowo trafiają one do bazy MSSQL.
Kodowanie polskich znaków podczas przegrywania danych
Przy przegrywaniu danych z plików DBF program automatycznie zmienia kodowanie polskich znaków na Windows 1250. Starsze programy mogły zapisywać polskie litery w innym kodowaniu, więc bez konwersji w bazie SQL pojawiłyby się znaki zastępcze. Replikator robi tę zamianę za administratora przy każdej replikacji.
Po przejściu na SQL dane da się łączyć jednym zapytaniem, zamiast przeglądać każdą tabelę osobno. Do jednej bazy sięgają raporty i aplikacja internetowa, każda na własnych uprawnieniach. Przy większej liczbie użytkowników rozbudowuje się serwer, a nie zestaw plików.
Serwer pozwala też zwiększyć bezpieczeństwo przechowywanych informacji, bo dostęp do tabel przydziela się konkretnym kontom. Prostsza staje się integracja z innymi systemami, ponieważ większość nowych programów oczekuje źródła danych w SQL. Dla przestarzałych formatów DBF to realna alternatywa.
Synchronizacja ręczna
Zalogowany użytkownik ADMIN może na żądanie uruchomić opcję Synchronizacja ręczna. W oknie zaznacza tabele, czyli pliki DBF, które mają zostać zreplikowane. W opisywanym przykładzie dostępne są dwie tabele kartotek. Po uruchomieniu opcji pojawia się okno informacyjne z postępem replikacji.
| Tryb | Kto uruchamia | Co się dzieje | Kiedy |
|---|---|---|---|
| Synchronizacja ręczna | Zalogowany użytkownik ADMIN | Zaznacza tabele, czyli pliki DBF, i obserwuje okno z postępem | Na żądanie, w dowolnym momencie |
| Zadanie Job | Aplikacja uruchomiona z parametrem Job: | Wykonuje się zapisane zadanie | Jednorazowo, od razu po starcie aplikacji |
Integracja danych SQL
Studio Replikator.net powstał z myślą o administratorach systemu, którzy muszą replikować dane. Aplikacja przenosi dane z siedmiu najpopularniejszych systemów bazodanowych do bazy MSSQL. Po uruchomieniu z parametrem Job: wykonuje zapisane zadanie. Zadanie wykonuje się jednorazowo, od razu po starcie aplikacji.
Replikator sam analizuje strukturę tabeli źródłowej i na jej podstawie buduje zapytanie INSERT, które dopisuje rekordy do bazy. Zapis tego polecenia opisuje składnia polecenia INSERT w T-SQL. Aplikacja podmienia też najbardziej znane zastrzeżone nazwy kolumn, na przykład USER i UPDATE, żeby zapytanie nie kończyło się błędem składni.
Import danych do bazy SQL
Studio Replikator tworzy dwa niezależne pliki dziennika: status.log i error.log. Do pliku status.log trafiają wpisy o uruchomieniu zadań replikacji i importu oraz o poprawnym zakończeniu skonfigurowanego zadania. Do error.log zapisywane są komunikaty o błędach replikacji lub importu. Tam też lądują problemy z zapisem i konwersją danych. Dodatkowo plik zawiera samo polecenie SQL. Oba pliki są niezależne: wpis o poprawnym zakończeniu zadania trafia do status.log, a szczegóły niepowodzenia do error.log.
| Plik | Co zapisuje | Kiedy do niego zajrzeć |
|---|---|---|
| status.log | Wpisy o uruchomieniu zadań replikacji i importu oraz o poprawnym zakończeniu zadania | Gdy trzeba potwierdzić, że zadanie przeszło |
| error.log | Komunikaty o błędach replikacji lub importu, problemy z zapisem i konwersją danych oraz polecenie SQL | Gdy replikacja zgłosiła błąd |
Przy błędzie zaglądaj najpierw do error.log: obok komunikatu zapisane jest polecenie SQL, które się nie powiodło.
Starsze systemy z formatem DBF działają dalej, bo nikt ich nie przepisał na nowszą technologię. Żeby połączyć taki system z bazą SQL, stosuje się replikację DBF do SQL. Stary program nadal zapisuje dane w plikach, a replikator przenosi je na serwer. Gdy dane z plików trzeba tylko jednorazowo wgrać do bazy, wystarczy opisany osobno import danych do bazy SQL.
Na czym polega replikacja DBF2SQL?
Replikacja DBF2SQL przenosi dane z baz w formacie DBF do baz opartych na SQL. Pozwala je synchronizować albo przenieść do nowego środowiska. Starsza aplikacja nadal działa, a nowy system ma dostęp do aktualnych danych. Podobny cel ma automatyczna synchronizacja danych, która utrzymuje zgodność tabel po stronie programu magazynowego.
Dlaczego replikacja DBF do SQL ma sens?
Replikacja łączy starszy system z nowszymi aplikacjami. Dane z plików DBF można wtedy analizować w narzędziach, które czytają z SQL, i używać ich w kolejnych procesach. Dane dostępne w systemach obsługujących SQL łatwiej też udostępniać i administrować nimi.
Jakie etapy ma replikacja DBF do SQL?
Proces zaczyna się od opisu tego, co leży w plikach. Dalsze etapy układają się tak:
- Identyfikacja struktury bazy DBF i danych, które mają zostać przeniesione.
- Utworzenie odpowiedniej struktury w bazie SQL, żeby dane dało się poprawnie zaimportować.
- Migracja samych danych i weryfikacja, czy zgadzają się z oryginałem.
- Wdrożenie mechanizmów synchronizacji, które na bieżąco aktualizują dane między systemami.
Weryfikacja ma sens przy każdej partii danych. Po przeniesieniu tabeli porównaj liczbę rekordów w pliku DBF i w tabeli SQL, a potem obejrzyj kilka polskich nazw w kolumnach tekstowych, bo to tam od razu widać błąd kodowania. Szczegóły przenoszenia innych zbiorów opisuje strona o migracji danych.
Którym firmom replikacja DBF do SQL się przydaje?
Replikacja pomaga firmom, które korzystają ze starszych systemów, a chcą unowocześnić zaplecze IT. Dotyczy to branż, w których działają aplikacje oparte na DBF i trzeba je połączyć z innymi rozwiązaniami biznesowymi. Firmy informatyczne, takie jak SoftwareStudio, oferujące usługi IT dla firm, prowadzą cały proces od analizy danych po wdrożenie.
Jakie możliwości daje przeniesienie danych do SQL?
Bazy SQL mają funkcje analizy i raportowania, których starsze systemy oparte na DBF nie oferują. Po migracji da się wprowadzić lepszy podział uprawnień i skalować system wraz z firmą. Współczesne programy internetowe oraz systemy ERP wymagają dostępu do danych w SQL, więc migracja przestaje być opcją.