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.
Jedną z najważniejszych cech architektury dbExpress, zapewniających jej wysoką efektywność, jest jednokierunkowy charakter jej zbiorów danych.
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.
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.
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.
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).
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ń.
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.
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.
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
if InputQuery('Hasło', 'Podaj hasło', Password) then
LoginParams.Values['User_Name'] := UserName;
LoginParams.Values['Password'] := Password;
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.
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.
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.
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.
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.
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.
...
wilmac1977