ADO (ActiveX Data Objects)

ADO (ActiveX Data Objects) to starsza technologia firmy Microsoft umożliwiająca aplikacjom dostęp do danych z różnych źródeł, w tym baz SQL.

ADO i jego znaczenie w dostępie do danych

ADO, czyli ActiveX Data Objects, należy do starszych technologii firmy Microsoft przeznaczonych do komunikacji pomiędzy aplikacją a źródłem danych. Nie jest to pojedyncza baza danych ani samodzielny silnik przechowujący rekordy. Jest to warstwa programistyczna, która pozwala aplikacji wysyłać zapytania, odbierać wyniki, przeglądać rekordy oraz wykonywać operacje modyfikujące dane. Dzięki temu kod programu może pracować z różnymi źródłami informacji bez konieczności tworzenia całkowicie odmiennego mechanizmu dla każdego rodzaju połączenia.

W praktyce ADO było często wykorzystywane w aplikacjach tworzonych w środowisku Windows, zwłaszcza w programach korzystających z baz SQL, plików bazodanowych oraz usług udostępniających dane przez mechanizmy zgodne z OLE DB lub ODBC. Technologia przyjęła model obiektowy, w którym poszczególne elementy odpowiadają za połączenie, wykonanie polecenia, odebranie zestawu rekordów i obsługę błędów. Takie podejście upraszczało budowę aplikacji, ponieważ czynności związane z komunikacją z bazą można było uporządkować według powtarzalnego schematu.

ADO kojarzy się przede wszystkim z klasycznym programowaniem systemów Windows, aplikacjami opartymi na Visual Basic, skryptami oraz starszymi witrynami internetowymi. W pewnym okresie rozwiązanie to stanowiło wygodny sposób na połączenie interfejsu użytkownika z bazą danych. Obecnie spotyka się je głównie w utrzymywanych systemach, programach branżowych i starszych aplikacjach, które nadal poprawnie realizują swoje zadania, lecz wymagają ostrożnej opieki technicznej.

ActiveX Data Objects na tle innych metod komunikacji

W architekturze aplikacji ADO pełni funkcję pośrednika. Program formułuje polecenie, wskazuje źródło danych i korzysta z obiektów udostępnianych przez bibliotekę. Rzeczywista obsługa konkretnego źródła zależy natomiast od odpowiedniego dostawcy danych. Dostawca odpowiada między innymi za sposób nawiązania połączenia, przekazanie zapytania oraz przekształcenie wyniku do postaci możliwej do odczytania przez aplikację. Z tego powodu ta sama ogólna logika programu mogła być stosowana przy różnych źródłach, choć szczegóły konfiguracji nadal miały znaczenie.

W porównaniu z bezpośrednim korzystaniem z niskopoziomowego interfejsu sterownika ADO oferuje wygodniejszy model pracy. Zamiast obsługiwać każdy etap transmisji osobno, można posługiwać się obiektami o jasno określonych rolach. Z drugiej strony dodatkowa warstwa nie usuwa wszystkich różnic pomiędzy silnikami baz danych. Składnia zapytań, sposób zwracania typów danych, obsługa transakcji oraz reakcja na błędy mogą zależeć od dostawcy. Dlatego przenoszenie starszej aplikacji pomiędzy różnymi bazami wymaga sprawdzenia nie tylko samego kodu ADO, lecz także zapytań i ustawień połączenia.

Warto odróżnić ADO od ADO.NET. Nazwy są podobne, lecz należą do różnych modeli programistycznych. ADO opiera się na wcześniejszych mechanizmach COM i OLE DB, natomiast ADO.NET zaprojektowano dla środowiska .NET, z innymi klasami, sposobem zarządzania danymi i organizacją projektu. W starszym programie próba mechanicznej zamiany jednego rozwiązania na drugie zwykle nie jest prostą podmianą biblioteki. Należy przeanalizować połączenia, parametry zapytań, obsługę wyników i zależności pomiędzy warstwą danych a interfejsem.

ADO w typowych scenariuszach działania aplikacji

Najczęściej pracę rozpoczyna się od utworzenia obiektu połączenia. W parametrach określa się źródło danych oraz sposób uwierzytelnienia, a następnie następuje otwarcie połączenia. Kolejny etap polega na przygotowaniu polecenia, na przykład zapytania odczytującego listę produktów, sprawdzającego stan dokumentu albo zapisującego zmianę w kartotece. Wynik może zostać zwrócony jako zestaw rekordów, który aplikacja odczytuje w określonej kolejności.

Obiekt rekordów umożliwia przechodzenie pomiędzy wierszami, pobieranie wartości pól i sprawdzanie, czy osiągnięto koniec wyniku. W prostym programie dane mogą być od razu prezentowane w formularzu. W bardziej rozbudowanym rozwiązaniu wynik jest przekazywany do kolejnej warstwy, która odpowiada za obliczenia, filtrowanie lub przygotowanie raportu. Zaletą takiego modelu jest rozdzielenie czynności: połączenie obsługuje komunikację, polecenie opisuje operację, a zestaw rekordów przechowuje rezultat.

ADO może być również używane do operacji zmieniających dane. Należy wtedy zwracać uwagę na parametry zamiast składać zapytania wyłącznie przez łączenie fragmentów tekstu. Parametry ułatwiają przekazywanie wartości zawierających spacje, znaki specjalne lub różne formaty dat. Ograniczają także ryzyko błędów wynikających z nieprawidłowego formatowania danych wejściowych. W systemach, w których zapis obejmuje kilka powiązanych operacji, znaczenie ma także prawidłowe użycie transakcji, aby częściowo wykonana zmiana nie pozostawiła niespójnego stanu.

W starszych aplikacjach spotyka się też kursory, blokady rekordów i tryby pracy zależne od dostawcy. Ustawienia te wpływają na sposób przewijania wyników, możliwość edycji oraz ilość danych pobieranych z bazy. Im bardziej szczegółowo skonfigurowany jest obiekt, tym ważniejsze staje się sprawdzenie zgodności ustawień z konkretnym sterownikiem i charakterem źródła danych.

Problemy spotykane przy obsłudze ADO

Jednym z częstych kłopotów jest brak możliwości otwarcia połączenia. Przyczyną może być niepoprawny ciąg połączenia, niedostępny dostawca, zmieniona nazwa źródła, niewłaściwe uprawnienia albo różnica pomiędzy środowiskiem, w którym aplikacja działała wcześniej, a obecnym komputerem. Komunikat błędu nie zawsze wskazuje dokładnie miejsce problemu, dlatego przydatne jest sprawdzenie kolejno konfiguracji, obecności wymaganych składników i dostępności samego źródła danych.

Problemy mogą pojawiać się również po zmianie systemu operacyjnego, instalacji aktualizacji albo przeniesieniu programu na komputer o innej architekturze. Starsza aplikacja może oczekiwać biblioteki lub dostawcy, który nie został zainstalowany razem z resztą programu. Czasem połączenie działa dla jednego użytkownika, lecz nie działa dla innego, ponieważ zapisane ustawienia, uprawnienia do katalogu lub sposób uwierzytelniania różnią się między kontami.

Drugą grupę stanowią błędy w samych zapytaniach. Zmiana nazwy tabeli, pola lub typu danych może spowodować nieprawidłowe wyniki albo zatrzymanie programu. Kłopotliwe bywają także daty, separatory dziesiętne, znaki kodowania i wartości puste. Jeżeli aplikacja zakłada określony układ danych, nawet niewielka zmiana w bazie może ujawnić się dopiero podczas wykonywania konkretnej funkcji.

Wydajność zależy między innymi od zakresu pobieranych danych oraz sposobu filtrowania. Odczytywanie całej tabeli tylko po to, aby wyświetlić kilka wierszy, może obciążać zarówno aplikację, jak i źródło danych. Warto sprawdzać, czy warunki są przekazywane do bazy, czy też filtrowanie odbywa się dopiero po pobraniu dużego zestawu rekordów. Znaczenie ma także zamykanie obiektów po zakończeniu pracy. Pozostawione połączenia mogą prowadzić do wyczerpania dostępnych zasobów i kolejnych błędów.

Wskazówki dotyczące ADO w starszym programie

Przed modyfikacją działającej aplikacji dobrze jest ustalić, z jakiego dostawcy danych korzysta program, gdzie zapisano ciąg połączenia oraz jakie źródła są wymagane. Należy zachować kopię konfiguracji i dokumentować każdą zmianę. Jeżeli problem pojawił się po przeniesieniu programu, pomocne bywa porównanie ustawień starego i nowego środowiska, wraz z wersjami bibliotek oraz uprawnieniami użytkownika.

Nie powinno się usuwać ani podmieniać składników związanych z ADO bez sprawdzenia, które aplikacje ich używają. Współdzielone biblioteki mogą być potrzebne kilku programom, a nieprzemyślana zmiana może spowodować nowe problemy. Bezpieczniej jest najpierw ustalić zależności, wykonać kopię danych i przetestować rozwiązanie na kopii środowiska. Dotyczy to szczególnie aplikacji, które zapisują informacje w bazie i nie mają łatwej funkcji cofania zmian.

W kodzie warto rozdzielić obsługę połączenia, wykonywanie poleceń i prezentowanie wyników. Ułatwia to ustalenie, czy błąd powstaje podczas otwierania źródła, przesyłania zapytania, odczytu pól czy wyświetlania danych. Przydatne jest także rejestrowanie komunikatów diagnostycznych bez ujawniania poufnych danych logowania. Dzięki temu można odtworzyć okoliczności awarii i ocenić, czy problem jest stały, czy występuje tylko przy określonych danych.

W przypadku komputera używanego do pracy z takim programem znaczenie ma również stan systemu, dysku, pamięci operacyjnej i nośnika, na którym przechowywane są pliki aplikacji. Objawy przypisywane połączeniu z bazą mogą wynikać z uszkodzeń plików, niestabilnego działania systemu albo problemów z dostępem do katalogu. Dlatego diagnoza powinna obejmować zarówno warstwę programu, jak i podstawowe środowisko sprzętowe.

Kiedy zgłosić problem z ADO do serwisu

Do serwisu warto zgłosić się wtedy, gdy aplikacja przestaje łączyć się ze źródłem danych po zmianie komputera, aktualizacji systemu lub awarii nośnika, a samodzielne sprawdzenie ustawień nie przynosi rezultatu. Pomocna będzie informacja o treści komunikatu, momencie występowania błędu oraz czynnościach wykonanych bezpośrednio przed pojawieniem się problemu. Jeżeli dane są istotne dla pracy, nie należy wielokrotnie uruchamiać operacji zapisujących bez upewnienia się, że kopia danych jest dostępna.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się diagnozą problemów z komputerami i aplikacjami działającymi w środowisku Windows, w tym z programami korzystającymi ze starszych mechanizmów dostępu do danych. W ramach analizy można sprawdzić stan systemu, zależności programu, konfigurację połączenia oraz podstawową kondycję sprzętu. Naprawy są z reguły realizowane do 3 dni roboczych, zależnie od zakresu usterki i dostępności wymaganych działań.

Przed przekazaniem sprzętu dobrze jest przygotować opis objawów, nazwę używanej aplikacji oraz informację, czy problem dotyczy odczytu, zapisu, logowania lub samego uruchamiania programu. Takie dane ułatwiają zawężenie przyczyny i ograniczają ryzyko przypadkowych zmian w bazie. W przypadku systemów korzystających z ADO szczególnie ważne jest zachowanie kopii plików danych oraz konfiguracji, ponieważ nawet drobna modyfikacja środowiska może wpływać na działanie całego programu.