Pożegnanie Clippera

Na rynku pojawia się coraz więcej narzędzi, ułatwiających migrację z baz stworzonych w Clipperze do baz relacyjnych. Zazwyczaj jednak narzędzia te nie rozwiązują wszystkich problemów.

Na rynku pojawia się coraz więcej narzędzi, ułatwiających migrację z baz stworzonych w Clipperze do baz relacyjnych. Zazwyczaj jednak narzędzia te nie rozwiązują wszystkich problemów.

Według Oracle Polska, aż 30 tys. polskich przedsiębiorstw korzysta z rozwiązań bazodanowych opartych na Clipperze. Oprócz prostych programów "z półki" w firmach działają tysiące aplikacji pisanych przez programistów na potrzeby przedsiębiorstw. Clipper przechowuje informacje w plikowej bazie danych. Takie rozwiązanie sprawdza się, gdy danych jest niewiele i nie ma potrzeby, by jednocześnie kilku użytkowników efektywnie korzystało z aplikacji.

RDD

W CA-Clipper 5.0, prawdopodobnie najstarszej wersji tego kompilatora, która jest jeszcze szeroko wykorzystywana, wprowadzono budowę modułową - warstwa "obsługująca" dane została oddzielona od bibliotek Clippera. Moduł dostępu do danych - RDD (Replaceable Data Driver) - realizuje pewien zbiór funkcji, z których korzystają wewnętrzne biblioteki Clippera. Dzięki takiej organizacji stało się możliwe powstawanie sterowników RDD (a właściwie bibliotek podmieniających oryginalny clipperowski sterownik), które zamiast z bazą plikową DBF, łączą się z wybranym motorem relacyjnej bazy danych. Od RDD wymagane jest tylko, by realizował wszystkie funkcje API, z których korzysta aplikacja (i również Clipper).

Na wykorzystaniu tej cechy opierają działanie rozwiązania promowane jako panaceum na migrację z CA-Clipper do relacyjnej bazy danych. Oracle we współpracy z firmą OTC oferuje Mediator, specjalny sterownik RDD do Oracle8. Informix oferuje pełniący analogiczną funkcję IDD. Istnieją rozwiązania typu OpenPath, które obsługują kilka różnych motorów baz danych. Takich rozwiązań można znaleźć wiele - wymagane API RDD jest stosunkowo proste i łatwa jest implementacja sterownika.

Problemy migracji

Mimo korzystania z ww. narzędzi, podczas migracji do relacyjnej bazy danych na pewno pojawi się kilka problemów.

Po pierwsze, z natury serwer relacyjnej bazy danych posługuje się językiem zapytań SQL. Wywołania Clippera muszą więc być tłumaczone w RDD na język SQL.

Po drugie, aplikacja w Clipperze może korzystać z funkcji agregujących (liczących sumę, średnią itp.). Funkcje te znajdują się poza modułem RDD i są liczone lokalnie, na maszynie klienckiej. W razie gdy aplikacja zażąda wykonania takiej operacji, to przez sieć zostanie załadowana cała tabela z bazy relacyjnej. Naturalne jest, że taki agregat powinien zostać szybko obliczony przez serwer, aby stacja robocza otrzymała tylko wynik.

Trzecia, najważniejsza przeszkoda wynika z tego, że rozwiązania polegające na wymianie RDD są ograniczone możliwościami kompilatora Clipper. Program może nadal korzystać w zasadzie z 640 KB, działa pod kontrolą DOS, występują problemy z uruchamianiem aplikacji pod Windows NT (a czasami także pod Windows 98/95). Nie ma pewności, że po wymianie RDD aplikacja będzie działała tak samo dobrze.

Projekt Harbour

Pojawił się inny sposób potraktowania migracji rozwiązań opartych na CA-Clipper. Zamiast wymiany wyłącznie modułu dostępu do danych, można utworzyć nowy kompilator języka xBase w 100% zgodny z CA-Clipper. Tak powstał projekt Harbour, którego celem jest stworzenie w pełni przenośnego kompilatora xBase. Harbour jest projektem typu open source, rozwijanym przez programistów z całego świata (także z Polski). Każdy ma do niego dostęp za pośrednictwem Internetu.

Harbour to zarówno translator, jak i kompilator plików źródłowych Clippera. Translator pozwala przekładać kod xBase na postać plików w C. Te mogą być następnie kompilowane przy użyciu niemal dowolnego kompilatora języka C. Planowane jest także włączenie translacji do Javy czy Pascala.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200