Delphi - MS SQL adatbázis kezelés Delphi-ből

Ily módon a kliens alkalmazásunk egész vékony lehet, az üzleti logikát pedig központosíthatjuk. A többrétegű alkalmazások 'legegyszerűbb' formája a háromrétegű alkalmazás. A megjelenítési réteg tartalmazza a felhasználói interfészt, az adatszolgáltatási réteg működteti az adatbázis funkciókat és az üzleti szabályok (business rules) rétege jelenti a középső réteget, az itt megvalósított funkciók miatt akarunk tulajdonképpen programot írni. A középső réteg, vagyis az alkalmazás szerver menedzseli az ügyfél és az adatbázis szerver közti adatforgalmat, ezért data broker-nek is nevezik. Bonyolultabb rendszerekben további rétegeket tehetünk az ügyfél és az adatbázisszerver közé. Ilyen lehet például egy security services broker, ami a tranzakciók biztonságára felügyel.

A többrétegű alkalmazások támogatása a Delphiben a MIDAS (Multi-tier Distributed Application Services Suite) technológiára épül. A MIDAS lényegében egy adatkommunikációs technológia. A MIDAS stílusú kommunikáció két résztvevője a provider és a client dataset, amelyek adatcsomagok (data packet) formájában cserélnek információt egymással. Alacsony szinten az adatcsomag nem más, mint egy byte-folyam, de szerencsére nekünk ezzel nem kell foglalkoznunk; táblákat fogunk küldözgetni, amik akár BLOBokat vagy beágyazott táblákat is tartalmazhatnak.

Nézzük meg röviden a résztvevőket.

A client dataset adatokat kap a providertől, azokat a belső memória cache-ében tárolja, és hozzáférést biztosít ezekhez az adatokhoz. Minden adatmódosítás egy naplóban kerül rögzítésre. Az eredeti adatok a client dataset Data property-én keresztül érhetők el, a napló pedig a Delta property-n keresztül. A client dataset által birtokolt adatok bármikor egy külső fájlba menthetők. Azon túl, hogy a client dataset adataihoz hozzáférünk és módosíthatjuk azokat, szűrhetjük, sorba rendezhetjük őket és kereshetünk bennük. A client datasetnek nincs tudomása az adatok forrásáról.

Az adatcsomagok felépítése a provider komponens feladata. Az adatok előkészítése teljes mértékben a programozó feladata, azok származhatnak egy SQL lekérdezésből, de akár byte-onként is előállíthatjuk őket tetszőleges forrásból. A végeredmény mindenképpen egy egységesített formájú tábla lesz. A tábla mezeinek típusa szinte bármi lehet, sztring, egész típusok, dátum, BLOB, sőt még dataset típusú is lehet. Az egyes mezőkhöz vagy sorokhoz megszorításokat (constraint) kapcsolhatunk, amivel szabályozhatjuk, hogy mi kerülhet az egyes mezőkbe. Amikor egy kliens alkalmazás frissíti a client dataset adatait, a megszorítások automatikusan érvényre jutnak. Ha egy megszorítás feltétele nem teljesül, a frissítés visszautasításra kerül, és kivétel generálódik.

Mihelyst az adatok bekerültek a client dataset belső cache-ébe, lehetőségünk van azokat módosítani. A client dataset nyilvántart minden módosítást, és memóriában tárolt indexeket tart karban annak érdekében, hogy az adatokat különféle sorrendben szolgáltathassa. Továbbá a client dataset támogatja a Document/View architektúrát, ami azt jelenti, hogy ugyanannak az adatcsomagnak több nézetét is létrehozhatjuk egyszerre. Ezt a műveletet klónozásnak (cloning) nevezik. Egy adatcsomaghoz annyi klónt gyárthatunk, amennyit akarunk.

Ha az adatcsomag valamely adatait sikeresen módosítottuk, frissítenünk kell a forrást is. Ez úgy történik, hogy a client dataset a módosításokat tartalmazó napló állományát (Delta property) elküldi a providernek. Ha az adatok forrása egy adatbázis, akkor a provider képes arra, hogy a változtatásokat automatikusan a megfelelő tábláknak küldje tovább. A frissítési eljárást a programozó teljes mértékben az ellenőrzése alatt tarthatja, ha akarja. Ha a napló egy rekordját nem sikerül érvényesíteni az adatbázisban, a provider a rekordot beírja a hibanaplóba (error log) a hiba szövegével és a rekord forrásbeli értékével együtt. Amikor az egész napló feldolgozása véget ér, a hibák számától függ, hogy a sikeres módosítások commitálódnak-e, vagy visszagörgetődnek. Az 'ingerküszöböt' mi adhatjuk meg. Ez után a provider a hibanaplót visszaküldi a client datasetnek. A visszakapott hibanapló alapján a client dataset végigmegy a saját napló fájlján, és a sikeres módosításokat az adatain is végrehajtja, majd a bejegyzéseket törli a naplóból. Ha problémás rekordot talál, egy esemény keletkezik. Ilyenkor például a felhasználó döntheti el, hogy mi történjen.

Háromféle adatfolyamot láthattunk tehát az előzőekben, amik szóba jöhetnek a client dataset és a provider közti kommunikációban.

1. Adatcsomag megy a providertől a client datasethez, és a belső cache-be kerül.
2. A módosításokat tartalmazó napló (change log) megy a client datasettől a provider felé.
3. A sikertelen módosításokat tartalmazó hibanapló (error log) megy a providertől a client dataset felé.

A MIDAS alapú alkalmazások alapvetően kétféle szerkezetűek lehetnek. Írhatunk monolitikus alkalmazásokat, amik mind a client dataset, mind a provider komponenst tartalmazzák. És írhatunk több alkalmazást is, ahol az egyik alkalmazás tartalmazza a providert, a másik a client dataset komponenst. Az első esetben a programozás során egyszerre látjuk mindkét komponens property-jeit, nem gond az adatcsomagot az egyiktől a másikig eljuttatni. A második esetben már arra is oda kell figyelnünk, hogy milyen módon juttatjuk el az adatcsomagot az egyik helyről a másikra. Használhatjuk a TCP/IP protokollt, az IIOP-t (CORBA) vagy az RPC-t (DCOM és DCE esetében).

Az alapok áttekintése után írjunk egy nagyon egyszerű programot.

Nyissunk egy új applikációt és egy új adatmodult. Az adatmodulra húzzunk le egy TDatabase és egy TQuery komponenst. A TDatabase komponenst kössük rá a Test1 aliasra, vagyis csatlakozzunk az SQL Server pubs adatbázisához. A TQuery komponenst kössük össze az adatbázissal, és az SQL property-be írjuk be: 'SELECT * from titles'. A MIDAS lapról húzzunk le egy TDataSetProvider komponenst, a DataSet property-je mutasson a Query-nkre.

Csináljunk egy TClientDataSet komponenst is, a ProviderName property-jében hivatkozzunk a TDataSetProviderre, majd tegyünk mellé egy TDataSource komponenst, hogy a client datasetet a vizuális komponensek is lássák. A TClientDataSet-et nyissuk meg (Active = true). Tegyünk fel egy TActionList komponenst is az adatmodulra, és csináljunk két Action-t (Érvényesít és Visszavon). Mindkét Action csak akkor legyen elérhető, ha a client datasetet már szerkesztjük, tehát az OnUpdate eseménykezelő függvény legyen a következő:

procedure Tdm1.ActionUpdate(Sender: TObject);
begin
  (Sender as TAction).Enabled := 
    (ClientDataSet1.State in dsEditModes) or 
    (ClientDataSet1.ChangeCount > 0);
end;

Az Érvényesítés OnExecute eseménykezelőjében érvényesítsük a client dataset változtatásait, hiba esetén azt jelezzük a képernyőn is.

procedure Tdm1.Action1Execute(Sender: TObject);
begin
  if ClientDataSet1.ApplyUpdates(0) > 0 then
       raise Exception.Create('Hiba!');
end;

A Visszavon OnExecuteja a következő:

procedure Tdm1.Action2Execute(Sender: TObject);
begin
  ClientDataSet1.CancelUpdates;
end;

Már csak a Form elkészítése van hátra. Tegyünk le két gombot (TButton), és kössük össze őket a két Action-nel. Tegyünk le egy TDBNavigatort és egy TDBGridet, és kapcsoljuk össze őket a client datasettel a TDataSource komponensen keresztül. Kész is a program, lehet futtatni.
Indítás után a Pubs adatbázis Titles tábláját látjuk a Provider-en és a Client TDataset-en keresztül. Ha módosítjuk a DBGrid adatait, a módosítások a client dataset Delta property-jében, vagyis a change log-ban gyűlnek. Ha a Visszavon gombra kattintunk, a CancelUpdates metódus meghívásával semmissé válnak a módosítások, vagyis kiürül a change log. Ha az Érvényesít gombra kattintunk, az ApplyUpdates metódus a naplót elküldi a client dataset ProviderName property-jében meghatározott providernek, megvárja, amíg az érvényesíti a változásokat az SQL Serveren, majd fogadja az error logot és ennek megfelelően alakítja a change logját. Visszatérési értékként a hibák számát kapjuk meg. Az ApplyUpdates metódus egy paramétert is kap; specifikálhatjuk, hogy legfeljebb hány hiba merülhet fel az update során. Ha ennél a számnál több hiba keletkezik, az összes változás visszagörög, egyébként commitálódik.

MS SQL adatbázis kezelés Delphi-ből

26. rész