CaIS ® Tapplication & Delphi OLE/COM

InterSystems CACHÉ post-relációs adatbáziskezelõ ésObjectScript alkalmazás futtató Rendszer

Objektum Orientált programozása

CACHÉ OBJECTEK HASZNÁLATA

szerzõdött VAR partner (Value Added Remarketing partner)

A dokumentáció változtatásának jogát fenntartjuk . Copyright (C) 2004-2005

Tel. : 06 20/ 441 4882 Fax.: 06 96/ 245 199

e-mail : m-soft@m-soft.hu

http\\:www.m-soft.hu

Cache & CaIS®

5. Object-Adatkezelés Objectscript nyelvben

Mivel alapvetően adatkezeléssel foglalkozunk , ezért a Persistent objektumról essék néhány szó . Az objektumtípus részletes leírását lsd.: Help-Documentation-Cache Class Reference .Cache-ban az objektumok elérérsére a következő parancsformát használjuk :

SET OREF=##class(Class.Object).Method(param,…)

Ahol OREF egy az adott típusú objektum változója , memóriába lemásolt szerkezeti képe . Ezt követöen a változókra , mezőkre, metódusokra, querykra a követkető szintaxissal hivatkozhatunk (Master.Article példánkban) :

SET OREF=##class(Master.Article).%OpenId("1111") Adott rekord elérése .SET NEVMEZO=OREF.nev Megnyitott rekord mezőjeDO OREF.Update(param1,….) Metódusok futtatása

Ha ninccs felnyitva az objektum , akkor használható a következőképpen is :DO ##class(Master.Article).Update(param1,….)

Peristent objektum fontosabb metódusai :%OpenId(kulcsmező(k),opció) kulcsmező: egyszerű pl.: "1205"

összetett esetében pl.: "1205||334||aa"opció : 0 – normál rekord kezelés

1 – rekord LOCK-olásos használat %Close metódus hívásáig aktív !!!Visszatérési értéke lehet $$$NULLOREF

ha a megadott rekord nem létezik .%DeleteId(kulcsmező(k)) Megadott kulcsú rekord törlése táblából (diskről)%New() Új rekord létrehozása memóriában%Save() Mező , rekord mentése diskre%Close() Objektum , rekord zárása LOCK feloldása

Objektumon belüli hivatkozásnál használatos a . . előtag is , hiszen az Object Architect programban egy adott objektum metódusában felesleges volna kiírnunk a saját objektum nevét . Helyette a . . előtag a megszokott : pl.: ..%OpenId(…) . lásd : Master.Article Update metódus kódja . Ebben a metódusban egy klasszikus rekord felviteli eljárást láthatunk . Elsőként megnyitjuk a kérdéses rekordot %OpenId –vel , majd ha a visszatérési érték $$$NULLOREF , akkor %New –al létrehozunk egy új rekordot . Ezt követik az egyes mezők értékadásai , majd a %Save mentés és a zárás %Close .

s oref=..%OpenId(kodp,1) S:oref=$$$NULLOREF oref=..%New() s oref.kod=kodp,oref.nev=nevp,oref.me=mep,oref.stdnetto=stdnettop s oref.afa=afap,oref.vtsz=vtszp,oref.minkesz=minkeszp d oref.%Save(),oref.%Close() k oref

Cache & CaIS®

Fontos : a rekord törlésére használatos DeleteId csak lezárt objektumra használható! Tehát ha előzőleg %OpenId –vel felnyitottuk az adattábla objektumot , törlés előtt %Close –al le kell zárnunk !

A metódusok is többféléek lehetnek . A characteristics panelon állíthatunk be néhány típus jellemzőt :

• Private : csak az objektumon belül hívható , külső hívás elől rejtett .• Final : ezen metódus nem írható(módosítható) az örökített objektumokban , csak

ezen eredeti verzióját tudjuk hívni• Class Method : alapértelmezett típus , örökíthető az adott objektum osztályban• SQL tárolt eljárás : ODBC-n keresztül hívható belső eljárás (alapvetően nem

SQL alapú , mivel nincs visszaadandó SQL row sora) . Alkalmazásokban köztes számításokra és batchmove komponenshez (delphi) érdemes használni .

Metód kódjának típusai :• Code : bármely object script forráskód , akár beágyazott SQL-el is

(&sql("SELECT … FROM … WHERE….),…)• Expression:egy számított kifejezés meghatározásához használható

(algoritmizálást igénylő számításoknál) , minden örökített objektumban ismerté válik .

• Call : meghatározhatjuk mely programnak,routine-nak kell futnia a metódus hívásakor , minden örökített objektumban ismerté válik .

• Generator : kombinálhatjuk a megadott kódot (object script) az objektum osztály paramétereivel , amelyek futási időben változhatnak . Ebben az esetben ezen metódust az Object Architect nem fordítja le , hanem futási időben a végleges értékekkel kerül majd fordításra .

Mint azt a mellékelt ábra is mutatja az általában használt metódusok zöme Class method típusú és Code kódszerkezetű . Az egyszerűbb számított kifejezéseket az expression metód típus helyett calculated field(property) –vel válthatjuk ki . Az SQL tárolt eljárás készítésekor ajánlatos visszatérési értéket definiálni , hogy a hívó program kapjon infor-mációt a futás eredményességéről, a paraméteráttadásnál pedig ügyelnünk kell a típus kompatibilitásra is .

Az előzőekben láthattuk , hogyan kezelhetjük egy Persistent objektum adattábláját , hogy hívhatjuk fel metódusait . A következőkben egy kissé összetettebb fogalomkörrel foglalkozunk , mégpedig a lekérdezésekkel . A lekérdezések(query) a CACHÉ Persistent definíciójában alapvetően kétféle alaptípusú lehet : %Library.SQLQuery vagy %Library.Query . Ez utóbit szokás object query-nek is nevezni . Itt most nem térünk ki a dinamikus , külsőSQL és SQLGateWay querykre , mivel ezek jórészt a két alaptípus környezet specifikus variációi .Ezen fejezetben a lekérdezések hívásáról és működtetéséről illene csak szólni , mégis tegyünk egy kis kitérőt , hogy megértsük a CACHÉ query típusok világát :

Cache & CaIS®

%Library.SQLQuery :Az SQL típusú lekérdezéseket a nevében is szereplő SQL lekérdező nyelvvel progra-mozhatjuk be . Mint az alábbi ábrán is láthatjuk a típus kiválasztásakor %Library.SQLQuery –t választottuk . Ha az új query gombot választjuk az Object Architect-ben , akkor az query varászló alapvetően az SQL típust feltételezi és SQL nyelven készíti el (írja meg a háttérben) helyettünk a lekérdezést .Megjegyzés: a query varázsló kezdő programozóknak kölcsönöz kellően nagy önbizalmat , de később minden komolyabb feladatnál rádöbbenünk használhatatlanságára . Egy mondatban : egy egyszerű teljes táblás lekérdezést feltételekkel és sorbarendezéssel el tud készíteni , de mihelyt GROUP BY-olni vagy több táblát megmozgatni szeretnénk , már használhatatlan .

Az SQLQuery-ről jó tudni , hogy ha lekérdezéseinket az Object Architect programban definiáljuk és ezeket felhívjuk a lefordított lekérdezésünk az ODBC driver alatti szinten fog futni . Vagyis 3-4szer lesz gyorsabb , mint ha az SQL kliens szoftver (pl.: Delphi SQLQuery komponens objektum,..) adná ki az SQL mondatot az ODBC driver SQL értelmezőjének . (És ez még nem minden ! Az Object queryknél még ezt a sebességet is túl fogjuk szárnyal-ni. ) Ne feledjük , ha a query SQL mon-datába manuálissan belejavítunk , bővítjük , a select utáni mezőfelso-rolásnak mindig szinkronba kell lenie a Row specification deklarációval . Máskülönben fordítási hibákat kapunk .A projection opciónál választhatjuk meg a lekérdezésünk másodlagos megjelenési formá(it)ját , egyszerre akár

többfélét is . Vagyis lehet egyszerre tárolt SQL eljárás és View-is . View esetében meg kell adnunk a View –kénti tábla megnevezését . (View: olyan tábla , amely egy lekérdezés végeredményeként születik meg . Elérésekor először mindig a query-je fut le , ezért várnunk kell a rekordok eléréséhez ! )Fontos : a CACHÉ megengedi a paraméterezett View alkalmazását , vagyis egy paraméterek szerint lekérdezett résztábla kivetítését önálló táblakénk ; viszont a legtöbb föleg MicroSoft SQL kliens eszközök nem támogatják a paraméterezett queryket , képtelenek kezelni azokat.%Library.Query :Az SQL nélküli query , mint neve is mutatja csak object script programozóknak ajánlott . Lényege , hogy az adatokat nem az SQL értelmezőn keresztül érjük el (SQL adatelérés a leglasabb elérési mód !!!) , hanem object vagy direkt eléréssel szólítjuk meg . Természetesen ezen querykben felhívhatunk más , már definiált queryket (akár

Cache & CaIS®

SQLQuery-t ) is ; ebben az esetben momdhatnánk : minek akkor az object query , hosz SQLQuery-t is felhívhatunk ,így nem lesz gyorsabb a lekérdezésünk . A felvetés jogos , így módosítjuk az object query használatának indoklását :

• Ha túl sok a feldolgozandó adatrekord , és SQL módban a futási idők már kritikusak. Ekkor az object queryben törekednünk kell a tisztán csak object és direkt elérés használatára .

• Ha túl bonyolult lekérdezést (kimeneti képet) kell előállítanunk : azonos mezőkben külömböző típusú adatok fognak szerepelni , túl bonyolult temporary adatszerkezetet kellene kezelnünk .

• Ha a lekérdezés során algoritmizálnunk kell , hiszen az SQL nem teljes értékű programozási nyelv .Ezen query-k SQL adat mondata minden esetben üres :

Egy object query-hez minden esetben tartozik egy querynévExecute , querynévFetch , querynévClose metódusok . Ezen metódusokban beprogramozott object script kóddal írhatjuk meg a lekérdezést . Az egyes metódusok funkcionálisan is elkülönülnek .

Execute (műveletvégzés,adatkeresés):Az object queryknek a visszatérési értékét mindíg %Library.Status típusúra kell állítani , hogy a külső SQL kliens eszközök , a query felhívásakor (CALL) a futási státuszt tudják ellenőriz- ni. A qHandle kötelező paraméter a query futása közben hordoz információkat a felhívott metódusok között , pl.: egy hiba lekezelésekor leállíthatja a query futását .

A query adatainak kereséséhez , átmeneti listakimeneti táblába történő leválogatásához a következő példa szerinti tagoltságot érdemes betartani .

Cache & CaIS®

Elsőként a stack előkészítését végezzük el (NEW) , majd a temporary fájl(globál) userhez kapcsolódó azonosítóját kell legenerálnunk . Fontos tudnunk , hogy a query-k futtatását a CACHÉ process manager úgy hajtja végre , hogy nem az aktuális $JOB processzünkbe illeszti be , hanem különálló önálló processként indítja el a queryt (a processt CacheSql előtaggal látja el : Cache Config Managerben állítható : Advenced-SQL-Cached Query RoutinePrefix) . Vagyis tudnunk kell melyik query átmeneti globál node-jai , melyik hívó programhoz is fognak tartozni . Az adatkeresés során , csak az Execute metódusban használatos ideiglenes segédtábláknál , fájloknál használható a $JOB függvény !Ezt követi a paraméterek feldolgozása , konvertálása , ellenőrzése . Ha minden rendben , elkezdődhet az adatok lekérdezése és átmeneti fájlba történő kigyűjtésük .Az adatok kigyűjtését a $$$OK zárja , jelezve a qHandler-nek , hogy a folymat sikeresen be-fejeződött valamint a tempID változót is közli a Fetch és Close metódusokkal .

Megjegyzés : az esetleges programozási hibákat az object query felhívásakor és futtatásakor az SQL kliens kezeli , akár le is nyelheti . Ha a CACHÉ ODBC beállításainál az ODBC log opciót bejelöltük , akkor viszont a CACHÉ Control Panel SQLError Log opciójában megtalálhatjuk a teljes object script hibaüzenetet , stack állapotot , stb….

Fetch (rekordok felnyitása , SQL eredmény rekord szerkesztése):

Cache & CaIS®

A Fetch metódus az Execute álltal előállított lekérdezés kimenetét soronként olvassa fel , majd minden egyes rekordot felolvasásva $ListBuild rekordszerkezetbe szerkesztve átadja az SQL kliensnek .

Fontos : a Fetch metódus row nevű mezőjében $ListBuild szerkezettel összeállított adatok sorrendjének , számának és típusának szigorúan egyezni kell ,a query fejében megadott Row specification felsorolással .Close (lezárás , temporary fájlok – stack törlése):A Close metódussal az átmeneti-ideiglenes fájlokat , változókat törölhetjük . A qHandler-t üresbe kell állítanunk , hogy az Execute ne kapjon ismételten vezérlést , majd a $$$OK rendszer változóval jelezhetjük a query futásának sikerességét.

Cache & CaIS®

Most kanyarodjunk vissza az eredeti feladathoz : Hogy hívhatjuk fel a lekérdezéseinket object script programjainkban(routine) . A lekérdezések bármely típusa (SQL-Object) azonos módon hívható , hívási interfészük azonos . A query típusok ismertetésekor egy különleges query típusra a dinamikus SQL-re nem tértünk ki , most ezt megtesszük mivel ezek használatában van az eltérés .A lekérdezések feldolgozásához a %ResultSet objektumot használhatjuk , amely rendelkezik a query-k futtatásához felügyeletéhez , manipulálásához szükséges metódusokkal . Az egyes komponenseinek hívási sorrendje a következő :

• %New("objectnév:querynév"):memóriában elkészíti a hivatkozott query futtatásá-hoz és adatainak row fogadásához szükséges területet

• Prepare("SQL lekérdezés string") : csak dinamikus query esetében használatos , ebben az esetben a %New hívásakor a querynév="SQL" .

• Execute(param1,…) : a megadott paraméterekkel (ha vannak) futtatja a lekérdezést /aktivizálja object query esetén az Execute metódust/

• Next() : lépteti a lekérdezés eredmény táblájának rekordmutatóját /aktivizálja object query esetében a Fetch metódust/

• Get("mezőnév") : az aktuális eredmény rekord adott mezőjének elérése .• %Close() : query resultset-jének zárása , memória felszabadítása .

Az egyes utasítások klasszikus sorrendje egy mintaprogramban a következő ;A mellékletben található Master.Article ListOne lekérdezését hívjuk fel , amivel a "1111" kulcsrekordú cikk rekordot keressük ki az adattáblából : Set result=##class(%ResultSet).%New("Master.Article:ListOne") Do result.Execute("1111") For Quit:'result.Next() Do . Write result.Get("nev"), result.Get("me"), result.Get("vtsz")! Do result.%Close()

Ugyanezt a műveletet dynamic query-ben is megírhatjuk , ekkor a hívó routine futásakor kapja meg az SQL értelmező a lekérdezés SQL paranccsát . A query értelem szerűen lassabb mint a lefordított %Library.SQLQuery , viszont futási időben még manipulálható az SQL parancsmondat és a paraméterezés beszerkesztése is :Set result=##class(%ResultSet).%New("%DynamicQuery:SQL") Do result.Prepare("SELECT nev, me, vtsz, afa FROM Master.Article WHERE kod = ?") Do result.Execute("1111") For Quit:'result.Next() Do . Write result.Get("nev"), result.Get("me"), result.Get("vtsz")! Do result.%Close()Megjegyzés : az SQL parancsban a ? karakter a paraméter helyét mutatja , esetünkben az Execute "1111" paramétert . Ha több kérőjel található az SQL parancsban , akkor az Execute-ban a megadott paraméterek sorrendisége szerint helyettesítődnek be !

Az adattípusú objectek object script nyelven történő kezelésének megismerése után , a következő részben ugyanezen CACHÉ komponensek kezelését fogjuk elsajátítani windows 4GL fejlesztőeszközzel (Delphi) . A fontos számunkra , hogy az Object Architect-ben megkonstruált , beprogramozott objektumok mind karakteralapú object script, mind windows grafikus Delphi felületről egyformán működtethetőek ; ezzel közös (egy helyen karbantartható) objektumokat használhatnak .

Cache & CaIS®

6. Object-Adatkezelés Delphi OLE/COM csatolással

Az InterSystems corporation a 3-as verziótól kezdve biztosítja a fejlesztők részére a teljes objektum csatolhatóságot ActiveX OLE felületen , bármely 4GL objektum orientált fejlesztőrendszer számára . Ezzel gyakorlatilag a CACHÉ objektum orientált adatbázis objektumait úgy érhetjük el pl.: Delphi környezetben , mint a Delphi saját Borland objektumait (pl.: TTable , TForm,…) . Ezek elsajátítása után hamar rájövünk ,hogy a 4GL fejlesztőeszközöket csak a felhasználóval folytatott interakcióra használjuk , mivel az adatbázis kezeléshez a CACHÉ saját objektumait szólíthatjuk meg .

A rend kedvéért tegyünk egy kis technikai kitérőt a MicroSoft ActiveX , OLE , COM csatolások világában ; már csak azért , mivel maga a gyártó MicroSoft is elég ködösen fogalmaz ezen saját megoldásairól . Sokszor a fejlesztők nagy részének fogalma sincs az egyes rövidítések lényegéről , csak gépiesen használják . Megjegyzés: az OLE-COM megnevezésekben egyébként maga a Delphi sem túl következetes , ami az InterSystems-nél OLE , ahhoz Delphiben Com library szükségeltetik !

OLE :Az adatmanipulációs eljárások fejlődését kell végigkísérnünk az OLE megértéséhez . Kezdetben a MicroSoft megalkotta a vágólapot , amivel kijelölt adatterületek váltak hordozhatóvá az alkalmazások között . Később rájöttek , hogy a kivág,másol majd beilleszt módszer elég macerássan használható rendszerezett adathalmazok esetében . Ekkor kifejlesztették a DDE (Dynamic Data/Database Exchange) módszert , amivel rendszerezett pl: adattáblák váltak hordozhatóvá az egyes alkalmazások között . Az objektum orientált környezetek megjelenésével már nem csak az adatokat , hanem a kapcsolatrendszereket , definíciókat is cserélni szerettek volna alkalmazások között . Ezen probléma megoldására dolgozták ki az OLE (Object Linking and Embedding) technológiát . Az OLE tehát alapvetően egy definíciós technika , ami a kiszolgáló és kliens alkalmazás közötti objek-tum kommunikációt definiálja .Kissé később a MicroSoft továbbfejlesztette az OLE technikát kiterjesztette kontrollok vezérlésére és automotion objektumokra is , ezt nevezte OLE2-nek .ActiveX:Az OLE 2 jótékony hatásai arra késztették a MicroSoft fejlesztőit , hogy az addíg .ocx fájlokban megírt windows kernel hívásokat objektumokra cseréljék és hívásukat OLE2 típusú felületté alakítsák . Az OLE2 szabványra átdolgozott windows kernel hívási szabványt nevezték el ActiveX kontrolloknak . A nevet aztán össze-vissza kezdték más gyártók is használni (pl.: Borland Delphi 3-4-ben az OLE felületet is ActiveX-nek nevezték , de más szoftverházak is keverték a megnevezés használatát) . A MicroSoft látva a káoszt , mégnagyobbat teremtett (mármint a káoszból) , ismét át-vissza nevezte az ActiveX-et OLE-ra (OLE2 jelző nélkül) , mondván : ez már nem az eredeti OLE (mint rövidítés) , hanem önálló egységes elnevezés(fantázianév , típusnév). A háttérben természetesen üzleti érdekek húzódtak , mivel a MicroSoft csak az OLE nevet védte le …COM:A COM az OLE által használt objektummodell (mármint a MicroSoft szerint) . Ez azonban annyira hihetetlen , hogy maga a MicroSoft Press által megjelentetett leírás , egész könyben magyarázza (nem túl érthetően) mindezt a földi halandó számára . A

Cache & CaIS®

gyakorlatban az OLE és COM kifejezéseket (még maga a MicroSoft is) egymás helyett össze-vissza használják . A COM-ot felfoghatjuk az OLE implementációjaként is , leggyakrabban ezen vetületeként használják . Vagyis egy OLE komponenseket befogadni és alkalmazni tudó fejlesz-tőeszköz , program COM típusúnak mondható . Erre aztán maga a MicroSoft adott (ön magyarázatának ellentmondó) bizonyítékot , mikor bejelentette a Java integrációját a COM-mal windows környezetben .

Először is a teljes objektum elérés támogatásához fel kell telepítenünk az InterSystems VisualM csomagját a Delphi packetek közé . A telepítés előfeltétele , hogy gépünkön már van

sikeresen telepített Cache 4.1.12 . Az ActiveX csomag telepítéséhez a Delphi fejlesztőkörnyezet Component > Import ActiveX control... menüpontban a következő komponensek hozzáadását kell elvégeznünk : CacheList ActiveX control module , CacheQuery ActiveX Control module , valamint a legfontosabb .ocx fájl VisualM 7.1 ActiveX Control module . A listából kiválasztást követően az Install gombra lépve telepíthetjük a komponens csomagokat . A telepítések után a Delphi rákérdez , hogy mentse-e az alap library listába az aktuális módosításokat , bővítésekt ; ezt hagyjuk jóvá .Helyes telepítést követöen az ActiveX komponensek közé a Delphi felveszi a VisualM objektumtípust , ahogy azt az alábbi ábra is mutatja (Caché kockás komponens) . Megjegyzés: Windows XP környezetet használva szükséges előzőleg telepíteni a Borland által kiadott Update packokat is #2 és #3-as verziókat . Ezekben javított windows alapkomponensek találhatóak . A sikeres telepítéshez ezen frissítések nélkülözhetetlenek . A külső nagy adatmennyiségű lekérdezések kezeléséhez pedig a QuickReport újabb frissített verzióját kell használnunk , legalább 3.0.4-es verziót XP esetében . A QuickReport külső cég terméke a QuSoft AS. cég fejleszti és támogatja továbbra is (az újabb Delphi verziókhoz a ChrystalReport vagy a VisualQueryBuilder-t forgalmazzák) . A régebbi QuickReport komponens <Cannot create file> hibaüzenettel fog elszállni ActiveX adatimportálás közben .

Cache & CaIS®

Azon Delphi unitokban ahol CACHÉ objektumokat akarunk felnyitni a ComObj unit komponenst be kell szerkesztenünk a használandó unitlistába :

Uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, Menus, ComObj;A CACHÉ objektumok működtetéséhez szükségünk lesz néhány alapváltozóra . A CACHÉ objektumot memóriában tároló változóra , melynek típusa variant , vagyis futási időben dől el az adatbázis kapcsolódás utáni definícióátadást követően az objektum változó szerkezete és mérete . Valamint egy connect string változóra is szükségünk lesz az adatbázis elérését , IP címét , Namespace nevét tároló stringre .

var CikkTDlg: TCikkTDlg; VALT:variant; constr:string;Meg kell teremtenünk a Delphi objektumhierarchiájában a csatolni kívánt CACHÉ OLE objektumok hierarchiájának helyét . Ezt a CreateOleObject Delphi metódussal tehetjük meg , ahol a gyártó InterSystems által megadott OLE definíciót kell paraméterként megadnunk : CacheObject.Factory .Az adatbázishoz történő kapcsolódás alapvetően kétféle módon történhet meg . A Connect metódusnak vagy konkrét elérési connect string szerkezetű stringet adunk meg (lsd.: mintapélda) , vagy a ConnectDlg metódust hívjuk fel (megjegyzésbe tett programsor) .

procedure CacheConnect;begin if constr='' then begin VALT:=CreateOleObject('CacheObject.Factory'); {constr := VALT.ConnectDlg();} constr:='cn_iptcp:127.0.0.1[1972]:MSOFT_PLUS'; VALT.Connect(constr); end;end;A ConnectDlg metódust használva a CACHÉ (Object Architect-nél már megszokott módon) a System to Connect to választó ablakot kapja a felhasználó , majd az itt kiválasztott opciónak megfelelő connect string (ablak alsó sorában látható) lesz a visszatérési érték .

Cache & CaIS®

Sikeres kapcsolódás után most lássuk hogy hívhatjuk fel CACHÉ objectjeink metódusait . A mellékelt példaprogramban a TcikkUpdate eljárás a CACHÉ Master.Article objektum Update metódusát hívja az adatkarbantartáshoz . A példában a CikkTDlg objektum változó nem más mint a cikk karbantartásához tartozó form , a benne lévő adatbekérő (adattábla) mezőket egy With .. do felnyitással rövidebb néven tudjuk szólítani . Elsőként egy New metódussal elkészítjük a CACHÉ objektum változóját (memóriában) , majd az így létrehozott és értéket kapott TcikkObj objektum változónak Update metódusát felhívva rögzíthetjük adatainkat :

. . .var CikkTDlg: TCikkTDlg; . . .procedure TCikkUpdate;var TcikkObj:variant; ObjRet:String;begin TcikkObj := VALT.New('Master.Article'); with CikkTDlg do ObjRet:=TcikkObj.Update(KodEdit.Text,CikknevEdit.Text,CikkMEEdit.Text, '',25,'',5);end;

Egy megadott kulcsú adatrekord létezésének vizsgálatára használhatjuk a CACHÉ-ben definiált query-inket . A Master.Article objektum tartalmaz egy rekord kereső lekérdezést a ListOne-t . Most lássuk Delphiben hogy használhatjuk egy egyszerű létezés vizsgálatra .Ebben az esetben a CACHÉ %ResultSet komponensére lesz szükségünk (ugyanúgy , mint object script programok esetében is) . A ResultSet CACHÉ objektum szintén variant típusúként lesz deklarálva , hiszen a Delphi nem tudhatja milyen szerkezetű lekérdezést fog működtetni . Elsőként a ResultSet metódussal definiáljuk a CACHÉ-ból felhívni kívánt lekérdezést (hasonló az object scriptben használt %New metódushoz…) , majd a már ismert Execute metódussal futtathatjuk le a querynket a megadott paraméterek felhasználásával . A Next metódus lépteti az eredménytábla pointerét

Cache & CaIS®

(azonos az object scriptben használttal) , a GetData pedig egy-egy mező elérésére szolgál . Fontos tudnunk , hogy itt nem használhat-juk a lekérdezés mezőinek neveit (hiszen ezt a Delphi jogosan nem is ismerheti…) , hanem a Row specification-ban megadott sorrend szerinti sorszámuk alapján hivatkozhatunk a mezőkre (ennek könnyítésére szokás a Row specification megjegyzésként történő bemásolása) . Végül a Close metódus zárja és takarítja az objektumot a memóriából .

Megjegyzés: a példában is látható , hogy az egyes metódusok ,melyeket használtunk object script-es programunkban is nem használják a % prefixet(ResultSet , Close) . A Delphi nem támogatja a % előtag eljárás és metódus név hivatkozását . Továbbá Delphiben nem tesszük ki az üres () paraméter zárójeleket sem !

Íme a lekérdezéssel támogatott létezés vizsgáló példa program(eljárás) :

procedure TCikkTDlg.KodEditExit(Sender: TObject);var rs:Variant;begin rs := VALT.ResultSet('Master.Article', 'ListOne'); rs.Execute(KodEdit.Text); while rs.Next do begin CikknevEdit.Text:=(rs.GetData(5)); CikkMEEdit.Text:=(rs.GetData(3)); end; rs.Close;end;Programjaink végén , vagy adatbázis zárásakor ne feledjük a CACHÉ adatbázis objektumunk lekapcsolását az EXE vagy DLL alkalmazásról . A Disconnect metódusnak egyébb hatása nincs , vagyis nem ürít memória cache-t (adatrögzítéseink az Update-nél ténylegesen megtörténtek , nincs virtuális memória vagy cache) , nem véglegesít válto-zásokat az adatbázisban .

procedure CacheDisConnect;begin VALT.DisConnect(constr); constr:='';end;

Mint láttuk Delphi OLE csatolással a CACHÉ objektumok kezelése kisebb szintaktikai eltérésekkel teljesen azonos az object scriptes programozásban megszokottal . Az ActiveX-nek is nevezett elérési móddal a CACHÉ adatkezelés ugyanolyan gyors és hatékony lessz mint object elérésű object script program változata . Teljes objektum elérés (metódusok , query-k) és gyors object adatelérés ; ezzel windows programozási környezet-ben is hatékonyak és CACHÉ közeliek tudunk maradni , vagyis az adatkezeléssel kapcso-latos műveleteket nem object pascalban , hanem továbbra is a CACHÉ saját object script nyelvében programozzuk be.

Cache & CaIS®

7. CACHÉ objektum adattáblák , SQL tárolt eljárások ODBC-n keresztül

Az univerzális adatelérés támogatására szolgál az ODBC (Open DataBase Connectivity) csatoló . Segítségével tetszőleges SQL kliens programmal használhatóvá válnak CACHÉ-ben tárolt adatbázisaink (MS-Excel/Query , MS-Access, …) , tárolt SQL eljárásaink . Fontos szabány , hogy a tárolt SQL eljárások hívási neve (pl.: SQL-ben hívott CALL hívásnál) a CACHÉ SQL Managerben látható teljes névvel kell hogy megeggyezzen , mint az alábbi ábrán :

Delphi formra is definiálhatunk SQL stored procedure komponenst a data access típusok közül . A komponens beállításainál a DatabaseName kiválasztása után az adatbázisban talál-

ható tárolt eljárások közül választhatunk a StoredProcName mezőben . Fontos ismernünk , hogy a Delphi nem olvassa fel korrekten az objektum nevét , vagyis a Class nevet lefelejti a névből . Ezt az ábrán látható módon manuálisan kell pótolnunk . Ha elfelejtjük <capacity not supported> hiba-üzenetet kapunk . Az SQL tárolt eljárás lefutását az Active (True/False) kapcso-

lóval tudjuk kapcsolgatni . Sikeres lefuttatás után (ha az eljárás %Library.SQLQuery ,vagyis lekérdezés) , az eredményt akár ki is vetíthetjük a formra , annak DBEdit mezőjébe . A művelethez szükség lesz a tárolt eljárás komponensre , egy adatforrás komponensre és a megjelenítő (Data Controll) DBEdit komponensre .

Cache & CaIS®

A DBEdit (Dara Controll) nem tud kommunikálni közvetlen adatelérő komponenssel (Data Access) , köztük egy kommunikátorra a DataSource komponensre van szükség . Beállítá-sukat a következőképpen kell elvégezni : A DataSource komponens alapadata , DataSet-je maga a tárolt SQL eljárás lesz . A Data Controll DBEdit adatforrása DataSource mezője pedig a

DataSource komponensre kell hogy mutasson . Ezen opció kiválasztása után a DBEdit komponenst hozzárendelhetjük egy a DataField mezőben kiválasztható query eredmény tábla mezőjével .

Az alábbi ábrákon végigkövethetőek az egyes lépések : 1. lépés SQL tárolt eljárás hozzárendelése DataSource adatsettjéhez.

3. lépés SQL tárolt eljárás kivetítetteredmény

2. lépés a DataControll DBEdit adatforrása a DataSet lesz

mezőjének hozzárendelése DBEdithezA példában egy lekérdezés egy eredménymezőjének kivetítését készítettük el . A példa elég esetlen , mivel egy lekérdezés kimenetét általában nem DBEdit komponensbe irányítjuk , hanem inkáb egy QuickReport listába , vagy ListBox komponensbe . Esetünkben az utolső eredményrekord mezőértékét fogjuk megkapni a DBEdit-be . Mivel a felhívott SQL tárolt eljárásunk a Master.Article ListOne lekérdezése , amely egy adott kulcsú elemet egy rekordját keresi ki , a végeredmény egyértelmű is lehet .A QuickReporttal viszont csak a következő fejezetekben fogunk megismerkedni . A Quick-Report mint összetett report generátor széles skáláját biztosítja a lekérdezések eredményeinek rendszerezett rész és összegfokozatos , fejléc-lábléc beszúrásával formázott megjelenítéséhez .

Cache & CaIS®

Szokásos alkalmazási területe a DataSource adatainak ComboBox-ba irányítása . Ezzel mintegy a leválogatott rekordok kiválasztását segíthetjük elő . Az alábbi combobox –ot használó példában találkozhatunk a ResultSet metódusban az Extent (az objektumban nem is létező) query névvel . Ezen kulcsszó hatására a táblánk alapértelmezett subscript rendezettsége szerinti lekérdezést (rekord pointer mozgatást) generálhatunk (CacheStorage esetében szekvenciális lista) .

ComboBox feltöltése CACHÉ adatállományból CACHÉ query segítségével :

Procedure TPagesDlg.ComboBox1Change(Sender: TObject);Var rs:Variant; begin comboBox1.Items.Clear; rs := VALT.ResultSet('CaISys.CUser', 'Extent'); rs.Execute(); while rs.Next do comboBox1.Items.Add(rs.GetData(1)); rs.Close; end;

Az adat objektumok object script és Delphi OLE/COM kezelésének elsajátítása után ezen mintapéldákat alkalmazás környezetekben fogjuk elhelyezni . Ehhez előbb meg kell ismerni a CACHÉ-re kifejlesztett saját termékünket a CaIS® Tapplication objektumát . Mind a CaIS® Tapplication , mind a Delphi TurboApplication objektumok alapja az eseményvezérelt programszerkesztés és gondolkodásmód elsajátítása .Ha sikerül elsajátítanunk ezen objektum orientált eseményvezérelt programozási módszert és kamatoztatjuk a CACHÉ adatbázis objektumainak (object script vagy OLE/COM) beágyazását , minden tekintetben a legoptimálisabb futási időket és adatbázis reakcióidőt tudhatjuk magunkénak .