Rozdział 8.

Tworzenie aplikacji bazodanowych za pomocą technologii dbExpress

dbExpress jest nową technologią Borlanda pozwalającą tworzyć efektywne aplikacje bazodanowe w Delphi 6.

Technologia dbExpress wyróżnia się pod względem funkcjonalności z co najmniej z trzech powodów. Po pierwsze, jest wygodniejszą i zgrabniejszą (z punktu widzenia projektanta) niż jej poprzedniczka — BDE. Po drugie, jest technologią międzyplatformową, umożliwiającą tworzenie aplikacji zgodnych z Kyliksem. Po trzecie — jest technologią rozszerzalną (extensible).

Podstawą architektury dbExpress są sterowniki dla różnych typów baz danych; każdy z tych sterowników implementuje zestaw interfejsów umożliwiających dostęp do danych specyficznych dla serwera. Współpracę aplikacji z tymi sterownikami organizują komponenty grupy DataCLX, funkcjonujące podobnie do komponentów BDE, tyle że bez niektórych zbędnych balastów.

Specyfika technologii dbExpress

Jedną z najważniejszych cech architektury dbExpress, zapewniających jej wysoką efektywność, jest jednokierunkowy charakter jej zbiorów danych.

Jednokierunkowe zbiory danych tylko do odczytu

Jednokierunkowy charakter zbiorów danych przesądza o braku buforowania rekordów, które jest pomocne jedynie przy nawigacji dwukierunkowej i modyfikacji danych. Rodzi to jednak pewne ograniczenia:

• Niedopuszczalne jest używanie metod Last() i Prior() klasy TDataSet, spośród metod nawigacyjnych można używać jedynie First() i Next().

• Niemożliwa jest modyfikacja danych (z powodu braku buforów edycyjnych). Możliwe jest jednak edytowanie rekordów za pomocą innych komponentów (TClientDataSet, TSQLClientDataSet) — zajmiemy się tym w dalszej części rozdziału.

• Jednokierunkowe zbiory danych nie realizują filtrowania — jako mechanizm odnoszący się do wielu rekordów, wymagałoby ono buforowania wielorekordowego.

• Jednokierunkowe zbiory danych nie obsługują pól przeglądowych.

dbExpress kontra BDE

W przeciwieństwie do BDE, dbExpress nie zużywa zasobów serwera na potrzeby zapytań związanych z metadanymi lub innych dodatkowych poleceń podczas realizacji żądań użytkownika. dbExpress nie konsumuje także tyle zasobów klienckich, co BDE, gdyż jednokierunkowe zbiory danych nie mają potrzeby cache'owania danych, zaś definicje metadanych przetwarzane są przez interfejsy implementowane w bibliotekach DLL.

dbExpress nie generuje także dodatkowych zapytań związanych np. z nawigowaniem po zbiorze danych, czy też odczytem pól BLOB; do serwera trafiają tylko zapytania wygenerowane przez aplikację użytkownika. Skutkuje to nie tylko większą efektywnością wykonywania aplikacji, lecz także czyni prostszym sam proces jej tworzenia.

dbExpress a aplikacje międzyplatformowe

Istotną zaletą technologii dbExpress jest jej przydatność zarówno dla Delphi 6, jak i dla Kyliksa — wykorzystuje ona komponenty CLX, a więc po skompilowaniu przez kompilator Kyliksa korzystające z niej aplikacje mogą być uruchamiane pod Linuksem. Możliwy staje się w ten sposób dostęp do międzyplatformowych systemów baz danych, jak MySQL czy InterBase.

Komponenty dbExpress

Wszystkie komponenty związane z technologią dbExpress znajdują się na stronie dbExpress palety komponentów (widocznej zarówno w aplikacji windowsowej, jak i w aplikacji CLX).

TSQLConnection

Jest to odpowiednik komponentu TDatabase i tak naprawdę jest do niego bardzo podobny (co z pewnością potwierdzą autorzy istniejących aplikacji wykorzystujących BDE). Nic w tym dziwnego, wszak obydwa te komponenty pełnią podobną funkcję: zadaniem komponentu TSQLConnection jest zapewnienie połączenia pomiędzy danymi serwera, a innymi komponentami dbExpress.

Funkcjonowanie komponentu TSQLConnection regulowane jest przez dwa pliki konfiguracyjne: dbxdrivers.ini oraz dbxconnections.ini. Są one instalowane jako elementy współdzielonych składników Borlanda, zazwyczaj w katalogu \Program Files\Common Files\Borland Shared\DbExpress. Plik dbxdrivers.ini zawiera listę wszystkich obsługiwanych przez dbExpress sterowników wraz z ustawieniami dotyczącymi tychże sterowników. Plik dbxconnections.ini zawiera natomiast listę tzw. „połączeń nazwanych”(named connections), będących odpowiednikami aliasów BDE — i związane z tymi połączeniami ustawienia. Możliwe jest zignorowanie zawartości pliku dbxconnections.ini i samodzielne dostarczenie parametrów połączenia; należy w tym celu ustawić na True właściwość LoadParamsOnConnect komponentu. Przykład takiego postępowania zaprezentujemy za chwilę.

Komponent TSQLConnection musi używać sterownika przeznaczonego dla konkretnego typu bazy danych i znajdującego się na liście zawartej w pliku dbxdrivers.ini.

Kompletny opis metod i właściwości komponentu TSQLConnection znajduje się w systemie pomocy. W niniejszym rozdziale ograniczymy się do praktycznych przykładów związanych z nawiązywaniem połączenia i tworzeniem nowych połączeń.

Nawiązywanie połączenia

W celu ustanowienia połączenia ze zbiorem danych, umieść na formularzu komponent TSQLConnection i ustaw jego właściwość ConnectionName, wybierając odpowiednią nazwę z listy rozwijalnej (w inspektorze obiektów) — powinny się tam znajdować co najmniej cztery pozycje: IBLocal, DB2Connection, MSConnection i Oracle. Na użytek niniejszego rozdziału wykorzystamy połączenie IBLocal (jeżeli nie zainstalowałeś serwera InterBase podczas instalacji Delphi 6, musisz zainstalować go teraz).

Zwróć uwagę, iż po wybraniu połączenia automatycznie zostaną zainicjowane niektóre inne właściwości, jak DriverName, GetDriverFunc, LibraryName i VendorLib; przypisane im wartości domyślne pochodzą oczywiście z pliku dbxdrivers.ini. Do ustawienia pozostałych właściwości i parametrów wykorzystać można właściwość Params, skojarzoną z edytorem prezentowanym na rysunku 8.1.

Rysunek 8.1. Edytor właściwości TSQLConnection.Params

Wskazówka

Domyślną wartością parametru Database jest database.gdb, na ogół bezsensowna. Należy ją zmienić na rzeczywistą specyfikację bazy danych — w naszym przykładzie będzie to baza Employee.gdb zlokalizowana w jednym z podkatalogów serwera InterBase (u nas C:\Borland\InterBase\examples\Database\).

Kiedy już właściwości komponentu zostaną prawidłowo ustawione, zmiana jego właściwości Connected na True spowoduje rozpoczęcie nawiązywania połączenia. Wyświetlone zostanie wówczas okno logowania, w które należy wpisać nazwę użytkownika i hasło — w naszym przykładzie użytkownik to sysdba, zaś hasło to masterkey.

Tworzenie nowego połączenia

Możliwe jest także tworzenie nowych „nazwanych” połączeń odnoszących się do wybranych baz danych. Okazuje się to pomocne np. w przypadku testowania nowej aplikacji na istniejącej bazie danych. By nie narażać na szwank zawartości bazy danych, pożądane jest utworzenie jej kopii i skojarzenie z nią nowego połączenia; przełączanie pomiędzy oryginałem a testową kopią bazy sprowadza się wówczas do zmiany właściwości ConnectionName.

Do tworzenia nowych połączeń służy edytor połączeń, uruchamiany w wyniku dwukrotnego kliknięcia komponentu TSQLConnection (lub za pomocą polecenia Edit Connection Properties z jego menu kontekstowego). Okno tego edytora jest przedstawione na rysunku 8.2.

Rysunek 8.2. Edytor połączeń komponentu TSQLConnection

Na pasku narzędziowym okna znajduje się pięć przycisków, służących do (kolejno) dodawania, usuwania, zmiany nazwy i testowania połączenia oraz wyświetlania ustawień dostępnych sterowników. Po kliknięciu pierwszego przycisku ukaże się okno zawierające pytania o wykorzystywany sterownik oraz nazwę dla nowego połączenia; sterownik można wybrać z rozwijalnej listy, zaś jako nazwę połączenia można wpisać dowolną nazwę odzwierciedlającą jego charakter, na przykład TestIBConnection. Po kliknięciu przycisku OK ujrzymy na liście parametrów to, co zawarte jest pod właściwością Params komponentu — ponownie trzeba będzie odpowiednio ustawić parametr Database. Po wykonaniu opisanych czynności można zamknąć edytor połączeń, ustawić na True właściwość Connected komponentu i zalogować się do bazy.

Pomijanie lub modyfikacja logowania

Ustawienie na False właściwości LoginPrompt spowoduje, iż okno logowania do bazy nie będzie wyświetlane, zaś nazwa użytkownika i hasło pobrane zostaną z parametrów (odpowiednio) User_Name i Password właściwości Params.

Zastąpienie standardowego okna logowania dialogiem własnego pomysłu jest możliwe dzięki zdarzeniu OnLogin (właściwość LoginPrompt musi być ustawiona na True). Oto przykładowe rozwiązanie:

procedure TMainForm.SQLConnection1Login(Database: TSQLConnection;

LoginParams: TStrings);

var

UserName: String;

Password: String;

begin

if InputQuery('Użytkownik', 'Podaj nazwę użytkownika', UserName) then

begin

if InputQuery('Hasło', 'Podaj hasło', Password) then

begin

LoginParams.Values['User_Name'] := UserName;

LoginParams.Values['Password'] := Password;

end;

end;

end;

W powyższym przykładzie dwukrotnie korzystamy z funkcji InputQuery() w celu pobrania łańcucha, za pośrednictwem okna opatrzonego tytułem i komentarzem. Przykład pochodzi z projektu LoginDemo.dpr, znajdującego się na załączonym krążku CD-ROM; projekt ten zawiera również ilustrację wykorzystania zdarzeń AfterConnect i AfterDisconnect.

Doraźne ustalanie parametrów połączenia

Ustawienia dokonane przez edytor połączeń, jak również wartość właściwości Params, to ustawienia domyślne, przechowywane w pliku dbxconnections.ini i pobierane z niego w czasie ustanawiania połączenia na etapie projektowania aplikacji. Ustawienia te wykorzystywane są w czasie wykonania programu — aplikacja nie korzysta z pliku dbxconnections.ini.

Możliwe jest jednak „podpięcie” do aplikacji pliku zawierającego charakterystyczne dla niej ustawienia połączeniowe. Należy wówczas ustawić na True właściwość LoadParamsOnConnect komponentu TSQLConnection, w rezultacie czego w momencie uruchomienia aplikacji wczyta on swe ustawienia połączeniowe z pliku określonego jako wartość o nazwie Connection Registry File klucza HKEY_CURRENT_USER\Software\Borland\DBExpress rejestru systemowego. Właściwe ustawienie tej wartości jest wówczas jednym z niezbędnych elementów procesu instalacyjnego aplikacji.

TSQLDataSet

Komponent TSQLDataSet reprezentuje jednokierunkowy zbiór danych zawierający dane pochodzące z serwera; pod pojęciem owego „zbioru danych” należy rozumieć tabelę, zapytanie SQL lub wynik procedury składowanej. Charakter zbioru danych określają dwie właściwości komponentu — CommandType i CommandText, których znaczenie wyjaśnione jest w tabeli 8.1.

Tabela 8.1. Znaczenie właściwości CommandType i CommandText komponentu TSQLDataSet

CommandType	CommandText określa…
ctQuery	…zapytanie SQL.
ctStoredProc	…nazwę procedury składowanej.
ctTable	…nazwę tabeli na serwerze bazy danych. Serwer oparty na technologii SQL automatycznie generuje instrukcje SELECT, powodujące pobranie wszystkich pól ze wszystkich rekordów tabeli.

Tak więc, gdy właściwość CommandType ma wartość ctQuery, właściwość CommandText zawiera treść zapytania SQL określającego strukturę i zawartość zbioru danych — na przykład SELECT * FROM CUSTOMER. Jeżeli zapytanie SQL nie określa zbioru wynikowego, lecz zawiera polecenie, należy w celu jego wykonania wywołać metodę ExecSQL().

Gdy CommandType przybiera wartość ctTable, CommandText zmienia się (w inspektorze obiektów) w listę rozwijalną, umożliwiającą wybór jednej z tabel bazy danych; ewentualne zapytania SQL niezbędne do pobrania zawartości wybranej tabeli generowane są automatycznie.

Wreszcie — dla właściwości CommandType równej ctStoredProc właściwość CommandText zawiera nazwę procedury składowanej. Wykonanie tej procedury następuje w wyniku wywołania metody ExecSQL() komponentu, nie zaś przez ustawienie właściwości Active na True.

Pobieranie zawartości tabeli

Aby pobrać zawartość tabeli, należy ustawić właściwość CommandType na ctTable i (po ewentualnym zalogowaniu się) wybrać nazwę żądanej tabeli z listy rozwijalnej towarzyszącej właściwości CommandText. Ilustruje to przykładowy projekt TableData znajdujący się na załączonym krążku CD-ROM.

Wyświetlanie wyniku zapytania SQL

Aby pobrać dane określone przez zapytanie SQL, należy ustawić właściwość CommandType na ctQuery i wpisać treść zapytania pod właściwość CommandText. Ilustrujący to projekt ma nazwę QueryData.dpr.

Wyświetlanie zbioru stanowiącego wynik procedury składowanej

Aby otrzymać zawartość zbioru określonego jako wynik procedury składowanej, należy określić typ zbioru (CommandType) jako ctQuery, zaś zawartością właściwości CommandText uczynić zapytanie SQL odnoszące się do procedury składowanej jako podmiotu. Jeżeli w charakterze przykładu weźmiemy następującą procedurę InterBase

CREATE PROCEDURE SELECT_COUNTRIES RETURNS (

RCOUNTRY VARCHAR(15),

RCURRENCY VARCHAR(10)

) AS

BEGIN

FOR SELECT

COUNTRY, CURRENCY FROM COUNTRY

INTO

:rCOUNTRY, :rCURRENCY

DO

SUSPEND;

END

to treścią wspomnianego zapytania mogłoby być

Select * from SELECT_COUNTRIES

Zwróć uwagę, iż używamy tu nazwy procedury składowanej w taki sam sposób, jak nazwy tabeli. Ilustracją opisanego wykorzystania procedury składowanej jest projekt SProcData na załączonym krążku CD-ROM.

Wykonywanie procedury składowanej

Aby wykonać procedurę składowaną, nie zwracającą zbioru wynikowego, należy ustawić ctStoredProc jako typ zbioru (CommandType), zaś jako CommandText podać nazwę procedury (którą można wybrać z listy rozwijalnej). W charakterze przykładu rozpatrzmy następującą procedurę:

CREATE PROCEDURE ADD_COUNTRY (

ICOUNTRY VARCHAR(15),

ICURRENCY VARCHAR(10)

) AS

BEGIN

INSERT INTO COUNTRY(COUNTRY, CURRENCY)

VALUES (:iCOUNTRY, :iCURRENCY);

SUSPEND;

END

Powoduje ona wstawienie do tabeli nowej pozycji, określającej nazwę kraju i jego walutę. Aby tę procedurę zrealizować, należy wywołać metodę ExecSQL() komponentu, na przykład jako reakcję na kliknięcie odpowiedniego przycisku:

procedure TForm1.btnAddCurrencyClick(Sender: TObject);

begin

sqlDSAddCountry.ParamByName('ICountry').AsString := edtCountry.Text;

sqlDSAddCountry.ParamByName('ICURRENCY').AsString := edtCurrency.Text;

sqlDSAddCountry.ExecSQL(False);

edtCountry.Text := '';

edtCurrency.Text := '';

end;

Dwie pierwsze instrukcje dokonują właściwego ustawienia parametrów, przypisując im wartości pobrane z kontrolek edycyjnych. Po wykonaniu procedury zawartość kontrolek jest usuwana. Pojedynczy, boolowski parametr metody ExecSQL() określa, czy parametry zapytania SQL mają być poddane preparacji (True), czy też nie (False).

Przykładowy projekt, ilustrujący wykonanie procedury składowanej za pomocą komponentu TSQLDataSet nosi nazwę ExecSProc.

Reprezentacja metadanych

Za pośrednictwem komponentu TSQLDataSet można pobierać nie tylko zawartość bazy danych, lecz także różnorodne informacje pomocnicze, określające strukturę tych danych, zwane metadanymi (metadata). Do pobierania różnych kategorii metadanych służy metoda SetSchemaInfo() komponentu:

procedure SetSchemaInfo(SchemaType: TSChemaType;

SchemaObjectName, SchemaPattern: String);

Pierwszy z parametrów określa kategorię metadanych do pobrania, drugi natomiast — nazwę konkretnego obiektu w danej kategorii: tabeli, procedury składowanej, jej parametru, indeksu itp. Ostatni, trzeci parametr zawiera tzw. wzorzec-maskę SQL, używany do filtrowania danych wynikowych. Dopuszczalne kategorie metadanych przedstawia tabela 8.2.

Tabela 8.2. Kategorie metadanych rozróżniane przez metodę TSQLDataSet.SetSchemaInfo()

Kategoria	Znaczenie
stNoSchema	Brak informacji o kategorii; obiekt załadowany zostaje danymi określonymi przez właściwości CommandType i CommandText, a nie metadanymi serwera.
stTables	Informacja o tabelach bazy danych, w zakresie określonym przez właściwość TableScope stowarzyszonego komponentu TSQLConnection.
stSysTables	Informacja o tabelach systemowych serwera. Jeżeli serwer nie wykorzystuje tabel systemowych do przechowywania metadanych, otrzymamy pusty zbiór danych.
stProcedures	Informacja o wszystkich procedurach składowanych na serwerze.
stColumns	Informacja o wszystkich kolumnach (polach) określonej tabeli.
stProcedureParams	Informacja o wszystkich parametrach określonej procedury składowanej.
stIndexes	Informacja o wszystkich indeksach zdefiniowanych dla określonej tabeli.

Dane wynikowe mają postać tabelaryczną i mogą zostać wyświetlone np. za pomocą komponentu TDBGrid. Ilustruje to przykładowy projekt SchemaInfo.dpr, znajdujący się na załączonym krążku CD-ROM; jego formularz główny został przedstawiony na rysunku 8.3.

Rysunek 8.3. Formularz projektu SchemaInfo.dpr

Gdy wybierzemy w polu opcji odpowiednią kategorię i klikniemy przycisk Pobierz metadane, uzyskamy zestawienie metadanych tej kategorii, ujęte w formę tabelaryczną. Treść procedury zdarzeniowej przycisku przedstawiamy na wydruku 8.1.

Wydruk 8.1. Pobieranie metadanych różnych kategorii w projekcie SchemaInfo.dpr

procedure TMainForm.Button1Click(Sender: TObject);

begin

sqldsSchemaInfo.Close;

cdsSchemaInfo.Close;

case RadioGroup1.ItemIndex of

0:

sqldsSchemaInfo.SetSchemaInfo(stSysTables, '', '');

1:

sqldsSchemaInfo.SetSchemaInfo(stTables, '', '');

2:

sqldsSchemaInfo.SetSchemaInfo(stProcedures, '', '');

3:

sqldsSchemaInfo.SetSchemaInfo(stColumns, 'COUNTRY', '');

4:

sqldsSchemaInfo.SetSchemaInfo(stProcedureParams, 'SHOW_LANGS', '');

5:

sqldsSchemaInfo.SetSchemaInfo(stIndexes, 'COUNTRY', '');

end;

sqldsSchemaInfo.Open;

cdsSchemaInfo.Open;

end;

Wywołanie metody SetSchemaInfo() powoduje odpowiednie ustawienie ukrytego pola FSchemaInfo:

procedure TCustomSQLDataSet.SetSchemaInfo(SchemaType: TSchemaType;

SchemaObjectName, SchemaPattern: string);

begin

FSchemaInfo.FType := SchemaType;

FSchemaInfo.ObjectName := SchemaObjectName;

FSchemaInfo.Pattern := SchemaPattern;

end;

Jak wynika z wydruku 8.1, ustawienie to dokonywane jest przy zamkniętym zbiorze danych — pobranie metadanych następuje przy jego otwarciu. Konstruktor komponentu ustawia typ tego pola na stNoSchema, co oznacza „normalne” pobieranie danych określone przez właściwości CommandType i CommandText; każda modyfikacja wspomnianych właściwości również „resetuje” typ pola do wartości stNoSchema.

Komponenty kompatybilne

Najbardziej wyraźnym przejawem „wstecznej kompatybilności” technologii dbExpress z BDE jest obecność w palecie takich komponentów, jak TSQLTable, TSQLQuery i TSQLStoredProc; funkcjonują one podobnie jak ich odpowiedniki z BDE, z ograniczeniami wynikającymi z jednokierunkowości zbioru danych. Nie oferują nic nowego ponad to, co udostępnia komponent TSQLDataSet.

TSQLMonitor

Komponent TSQLMonitor okazuje się bardzo przydatny w procesie śledzenia aplikacji SQL; rejestruje on polecenia SQL używane w komunikacji z komponentem połączeniowym TSQLConnection, wskazywanym przez swą właściwość SQLConnection. Rejestrowane polecenia przechowywane są na liście łańcuchów wskazywanej przez właściwość TraceList; zawartość tej listy można skopiować np. do komponentu TMemo w celu czytelnego jej wyświetlenia — tak też uczyniliśmy w naszym przykładowym projekcie SQLMonitor.dpr, czego świadectwem jest rysunek 8.4.

Rysunek 8.4. Wynik przykładowego śledzenia aplikacji za pomocą komponentu TSQLMonitor

Wskazówka

Ustawienie na True właściwości AutoSave komponentu TSQLMonitor powoduje samoczynne zapisywanie listy komunikatów w pliku o nazwie określonej przez właściwość FileName.

Edytowalne, dwukierunkowe zbiory danych dbExpress

Jak dotąd komponenty dbExpress jawiły się nam jako realizacja idei jednokierunkowego, niemodyfikowalnego zbioru danych — no, może z wyjątkiem procedury składowanej ADD_COUNTRY. Nie oznacza to jednak, iż baza danych, w połączeniu z którą funkcjonują komponenty dbExpress, nie da się za ich pomocą w ogóle edytować; za chwilę przedstawimy komponent, który umożliwia nie tylko dwukierunkową nawigację po zbiorach danych dbExpress, lecz także modyfikację danych na serwerze.

TSQLClientDataSet

Komponent TSQLClientDataSet skrywa w sobie dwa komponenty — TSQLDataSet i TProvider; pierwszy z nich zapewnia mu efektywny dostęp do danych, drugi natomiast — dwukierunkową nawigowalność i możliwość edycji danych.

W architekturze komponentów danej aplikacji komponent TSQLClientDataSet reprezentuje zbiór danych, podobnie jak TSQLDataSet: z jednej strony związany jest z komponentem połączeniowym za pomocą swej właściwości DBConnection, z drugiej natomiast skojarzony jest z komponentem TDataSource poprzez właściwość DataSet tego ostatniego. Możesz się o tym przekonać, analizując przykładowy projekt o nazwie Editable.dpr, znajdujący się na załączonym krążku CD-ROM.

Uruchomiwszy wspomniany projekt, możesz poruszać się po zbiorze danych w obydwu kierunkach, jak również dodawać, modyfikować i usuwać jego rekordy. Gdyby jednak docelowy zbiór danych zamknąć, okazałoby się, iż po tych zmianach nie ma śladu, gdyż zostały przeprowadzone jedynie w pamięci aplikacji-klienta. Aby nadać im trwały charakter, należy wywołać metodę ApplyUpdates() komponentu TSQLClientDataSet. W naszym przykładowym projekcie wywołujemy ją w procedurze SQLClientDataSet1AfterPost(), obsługującej zdarzenia AfterDelete i AfterPost, co powoduje aktualizację danych na serwerze rekord po rekordzie.

Notabene postępowanie takie nie jest bynajmniej charakterystyczne dla technologii dbExpress; na gruncie technologii MIDAS na identycznej zasadzie funkcjonował komponent TClientDataSet, czego obszerny przykład zamieściliśmy w rozdziale 33. książki „Delphi 4. Vademecum profesjonalisty”.

Wskazówka

Komponent TSQLClientDataSet nie udostępnia programiście swych pomocniczych komponentów TSQLDataSet i TProvider — są one wskazywane przez jego prywatne pola FDataSet i FProvider, zaś właściwość Provider jest właściwością chronioną (protected). Chcąc dowolnie manipulować ich właściwościami, musimy więc użyć ich niezależnych egzemplarzy, zamiast komponentu TSQLClientDataSet.

Realizacja aplikacji dbExpress

Bazodanową aplikację opartą na technologii dbExpress można zrealizować na dwa sposoby: jako monolit zawierający statycznie dołączone sterowniki do obsługi baz danych, bądź też ze sterownikami wydzielonymi w postaci bibliotek DLL. W pierwszym przypadku należy dołączyć do projektu moduły wyszczególnione w tabeli 8.3.

Tabela 8.3. Moduły wymagane w monolitycznej wersji aplikacji dbExpress

Moduł	Przeznaczenie
dbExpInt	Połączenie z bazami danych InterBase
dbExpOra	Połączenie z bazami danych Oracle
dbExpDb2	Połączenie z bazami danych DB2
dbExpMy	Połączenie z bazami danych MySQL
CrtL, MidasLib	Wymagane przez aplikacje wykorzystujące komponenty klienckich zbiorów danych, jak TSQLClientDataSet.

Realizując aplikację w wersji z wydzielonymi sterownikami, powinniśmy dołączyć do niej wybrane (lub wszystkie — zależnie od potrzeb) biblioteki spośród wymienionych w tabeli 8.4.

Tabela 8.4. Biblioteki DLL wymagane przez aplikację dbExpress w wersji rozdzielonej

Biblioteka	Przeznaczenie
dbexpint.dll	Połączenie z bazami danych InterBase
dbexpora.dll	Połączenie z bazami danych Oracle
dbexpdb2.dll	Połączenie z bazami danych DB2
dbexpmy.dll	Połączenie z bazami danych MySQL
Midas.dll	Wymagane przez aplikacje wykorzystujące komponenty klienckich zbiorów danych, jak TSQLClientDataSet.

Podsumowanie

Technologia dbExpress umożliwia efektywny dostęp do danych, niemożliwy do zrealizowania za pomocą BDE. Owa efektywność wiąże się jednak z ograniczeniami w postaci jednokierunkowego charakteru zbiorów danych i niemożności ich (bezpośredniej) modyfikacji. Ograniczenia te można jednak przełamać za pomocą komponentów TSQLClientDataset i TClientDataSet, zapewniających wewnętrzne buforowanie oraz transakcyjne uaktualnianie danych na serwerze, za pomocą metody ApplyUpdates().

Spośród dostępnych w Delphi technologii bazodanowych, w chwili obecnej jedynie dbExpress umożliwia tworzenie aplikacji międzyplatformowych.

2 Część I ♦ Podstawy obsługi systemu WhizBang (Nagłówek strony)

2 C:\WINNT\Profiles\adamb\Pulpit\Delphi\08-dbexpress.doc

---