TDD az Oracle tárolt eljárásokhoz. Oracle SQL tárolt eljárások hívása és Oracle eljáráshívás végrehajtása

A tárolt eljárás olyan program, amely bizonyos műveleteket hajt végre az adatbázisban lévő információkon, miközben azokat magában az adatbázisban tárolják. Az Oracle-ben a tárolt eljárások PL / SQL és Java nyelven írhatók.

A tárolt eljárások bemeneti paramétereket vehetnek fel, és eredményeket adhatnak vissza. Ellentétben a triggerekkel, amelyek egy adott táblához vagy nézethez tartoznak, a tárolt eljárások az adatbázis egészéhez tartoznak. Bármely, az adatbázist használó folyamat meghívhatja őket, feltéve, hogy a folyamat megfelelő jogosultsággal rendelkezik.

A tárolt eljárásokat számos célra használják. Míg az adatbázis-adminisztrátorok rutin adminisztrációs feladatok elvégzésére használják őket, elsődleges felhasználásuk az adatbázis-alkalmazásokban van. Ezek a rutinok meghívhatók olyan alkalmazási programokból, mint például a Java, C #, C ++ vagy VB.Net, valamint VBScript vagy JavaScript nyelven írt webszkriptekből. Ezenkívül ezek az eljárások interaktívan meghívhatók az SQL * Plus parancshéjból.

A tárolt eljárásoknak a következő előnyei különböztethetők meg:

Az alkalmazáskóddal ellentétben a tárolt eljárások soha nem kerülnek továbbításra az ügyfélszámítógépekre. Mindig az adatbázisban találhatók, és a DBMS hajtja végre azon a számítógépen, ahol az adatbázis-kiszolgáló található. Így biztonságosabbak, mint az újraterjeszthető alkalmazáskódok, és csökkentik a hálózati forgalmat is. A tárolt eljárások fokozatosan válnak az alkalmazáslogika preferált megvalósítási módjává az interneten és a vállalati intraneten. A tárolt eljárások másik előnye, hogy a bennük lévő SQL utasításokat a DBMS fordító optimalizálhatja.

Tárolt eljárási példa

Tegyük fel, hogy a példánk megköveteli, hogy információkat adjunk az adatbázishoz az új ügyfelekről és arról, hogy mely művészek érdeklik őket. Különösen a megrendelő nevét és telefonszámát kell rögzíteni, valamint a választott nemzetiségű összes művészhez társítani kell.

A 4.6-os lista egy tárolt eljárást mutat be, amely végrehajtja ezt a feladatot. A Customer_Insert nevű eljárás négy paramétert vesz fel: newname (új ügyfél neve), newareacode (régiókód), newphone (telefon) és artistnationality (előadó nemzetisége). Az IN kulcsszó azt jelzi, hogy ezek a paraméterek mindegyike be van adva. A kimeneti paraméterek (amelyekkel ez a rutin nem rendelkezik) vannak jelölve kulcsszó OUT, és a bemenetet és a kimenetet egyaránt betöltő paraméterek az IN OUT-tal kombinálva vannak. Kérjük, vegye figyelembe, hogy a paraméterhez csak az adattípus van megadva, a hossz nincs megadva. Az Oracle a szövegkörnyezet alapján határozza meg a hosszt.

Felsorolás 4.6.

ELJÁRÁS LÉTREHOZÁSA VAGY CSERÉJE Customer_Insert (
newname IN char, newareacode IN char, newphone IN char,
művésznemzetség IN char
MINT
sorszám egész szám (2);
CURSOR artistcursor IS SELECT ArtistID FROM ARTIST
WHERE Nemzetiség = művésznemzetiség;
KEZDŐDIK
SELECT Count (*) AZ ÜGYFÉL sorszámába
WHERE Név = újnév ÉS Területkód = newareacode AND PhoneNumber = új telefon;
IF rowcount> 0 THEN BEGIN
DBMS_OUTPUT.PUT_LINE ("Van kliens a DB-ben! A szám" I I rowcount); VISSZATÉRÉS;
VÉGE; VÉGE HA;
BEHELYEZÉS AZ ÜGYFÉLBE
(CustomerlD, Name, AreaCode, Phone Number)
ÉRTÉKEK (CustID.NextVal, newname, newareacode, newphone);
FOR artist IN artistcursor LOOP
BEHELYEZÉS A CUSTOMER_ARTIST_INT BESZÁMOLÓBA (CustomerlD, ArtistID)
ÉRTÉKEK (CustID.CurrVal, artist.Artist ID); VÉGE HUROK;
DBMS_OUTPUT.PUT_LINE ("Kliens hozzáadva!");
VÉGE;
/

A változó deklaráció szakasza az AS kulcsszót követi. A SELECT utasítás egy artistcursor nevű kurzorváltozót határoz meg. Ez a kurzor az ELŐADÓ táblázat sorait választja ki az adott nemzetiségű összes művész feldolgozásához.

Az eljárás első részében azt ellenőrizzük, hogy az adatbázis tartalmaz-e információkat erről a kliensről. Ebben az esetben nem történik semmilyen művelet, és egy üzenet jelenik meg a felhasználó számára az Oracle DBMS_OUTPUT csomag használatával. Felhívjuk figyelmét, hogy a következő szintaxist használják a változó karakterláncának és értékének megjelenítésére:

DBMS_OUTPUT.PUT_LINE ("<строка>"ÉS<переменная>);

A felhasználó csak akkor kapja meg ezt az üzenetet, ha az eljárást az SQL * Plus-ból hívják meg. Ha az eljárást más módon hívják meg, például az interneten keresztüli böngésző használatával, a felhasználó nem fogja látni ezt az üzenetet. Ahhoz, hogy a felhasználót értesítse a hibáról, a fejlesztőnek egy out paramétert kell használnia, vagy kivételt kell tennie.

Ezenkívül az ilyen üzenetek láthatóvá tételéhez futtassa a parancsot

Állítsa be a szerverkimenetet;

Ha az SQL * Plus használatakor nem lát üzeneteket, amelyeket az eljárások megjelenítenek, akkor valószínűleg nem hajtotta végre ezt az utasítást.

A 4.6-os listában szereplő eljárás többi része beilleszti az új ügyfél adatait, majd a kiválasztott nemzetiséghez tartozó összes előadón áthalad. Vegye figyelembe a speciális PL / SQL konstrukció FOR artist IN artistcursor használatát. Ez a kialakítás több célt is szolgál. Először is megnyitja a kurzort, és beolvassa az első sort. Ezután szekvenciálisan feldolgozza a kurzor alatti összes sort, és a feldolgozás végén átadja a vezérlést a FOR után következő utasításra. Vegye figyelembe azt is, hogy az aktuális sor ArtistID oszlopa az artist.ArtistID szintaxissal érhető el, ahol az előadó egy FOR ciklusváltozó neve, nem pedig kurzor.

Az eljárás megírása után le kell fordítani és el kell menteni az adatbázisba. Ha az eljárás szövegét fájlba mentjük, akkor az eljárás a parancs beírása után automatikusan lefordításra kerül és mentésre kerül az adatbázisba

indítsa el az Eljárás_fájl_neve

Ha valamit rosszul ad meg, fordítási hibákat tapasztalhat. Sajnos az SQL * Plus nem jeleníti meg automatikusan ezeket a hibákat, hanem egy "Figyelmeztetés: Az eljárás fordítási hibákkal készült" üzenetet jelenít meg. A hibák megtekintéséhez írja be a következő parancsot:

Hibák megjelenítése;

Ha nem volt szintaktikai hiba, akkor "Eljárás létrehozva" üzenet jelenik meg. Most már meghívhatja ezt az eljárást az EXECUTE vagy EXEC paranccsal:

Exec Customer_Insert ("Michael Bench", "203", "555-2014", "US");

Ha hibák fordulnak elő futás közben, a hibajelentésben szereplő sorszámok nem egyeznek meg a szövegszerkesztőben látható sorszámokkal.

Az egyik közelmúltbeli projektünk során komoly problémával szembesültünk. Az általunk fejlesztett webalkalmazásnak a pénzintézet belső adatbázisát kellett használnia. Biztonsági okokból a hozzáférés nagyon korlátozott volt: az esetleges változtatásokat tárolt eljárásokkal kellett végrehajtani, az adatokat pedig csak nézetek segítségével kellett beolvasni. Így az alkalmazásnak összetett adatmanipulációkat kellett végrehajtania anélkül, hogy fogalma lett volna azok felépítéséről. A fő bökkenő számunkra az volt, hogy alkalmazásunk nagy és összetett eljárásoktól vált függővé, amelyekhez nem voltak automatizált tesztek.

Kis guglizás után azt találtuk, hogy a szabványos Oracle SQL Developer eszközkészlet rendelkezik automatizált tesztek létrehozására alkalmas funkciókkal. Azonnal elkezdtük tanulmányozni. És bár a legbonyolultabb eljáráshoz már a megírása után teszteket kellett készíteni, ez az eszköztár ennek ellenére számos hiba kiküszöbölésében segített, és nagyban megkönnyítette a funkcionalitás bővítését és az átalakítást. Az alábbiakban példát mutatok be a TDD használatára tárolt eljárások létrehozására, valamint megosztom az eszközkészlettel kapcsolatos tapasztalataimat.

Használati példa

Tegyük fel, hogy az ügyfél rendelkezik meglévő alkalmazás amely lehetővé teszi ügyfelei számára SMS üzenetek küldését. Egy másik csapat új alkalmazást fejleszt, aminek párhuzamosan kell futnia a meglévővel, így jó lenne, ha lenne egy közös hely az üzleti logikának.

Adatstruktúra

Az alkalmazás a következő adatstruktúrát használja:

TÁBLÁZATÜGYFELEK LÉTREHOZÁSA (AZONOSÍTÓKÉNT NEM NULL ALAPÉRTÉKELÉSRE LÉTREHOZOTT AZONOSÍTÓ SZÁM, NVARCHAR2 NÉV (255) NEM NULL, EGYENLEG SZÁMA (*, 2) ALAPÉRTÉKELÉS 0 NEM NULL, IS_ACTIVE NUMBER (1) ALAPÉRTELMEZETT (DEFAULT1)0 NEM NULLA); TÁBLÁZAT MESSAGE_QUEUE LÉTREHOZÁSA (AZ AZONOSÍTÓ SZÁM ALAPÉRTELMEZÉSRE LÉTREHOZOTT IDENTITY NEM NULL, ID_CLIENT SZÁM NEM NULL, FELADÓ VARCHAR2 (20), CÍMZÉS VARCHAR (20), NVARCHAR2 ÜZENET (255) NOT NULL, QUESTAUEDNULLTIMEONTIMEONECONONECON.MP NULLA); TÁBLÁZATI TRANZAKCIÓK LÉTREHOZÁSA (AZONOSÍTÓ SZÁM, ALAPÉRTELMEZÉSRE LÉTREHOZOTT IDENTITY NEM NULL, ID_CLIENT SZÁMA NEM NULL, ÉRTÉKSZÁM (*, 2) NEM NULL, TRANSACTION_TIME IDŐBÉLYEG AZ IDŐZÓNA ALAPÉRTELMEZETTSÉGÉVEL CURRENT_TIMESTAMP);

A rövidség kedvéért az elsődleges és az idegen kulcs definícióit elhagytuk.

A környezet kialakítása

Az SQL Developer egységtesztelése adatbázist használ a tesztek, azok beállításai, könyvtárai és a végrehajtási eredmények tárolására. Ebből a célból erősen ajánlott tesztelésre létrehozni egy felhasználót, majd létrehozni egy repository-t az adatbázisában. Ezt a folyamatot részletesebben az egységtesztelési dokumentáció írja le.

Oracle tesztelési terminológia

Az Oracle által használt tesztelési terminológia kissé eltér az általánosan elfogadott xUnit terminológiától:

Meglepetések

Miközben az alkalmazással dolgoztunk, azt tapasztaltuk, hogy az nem mindig működött úgy, ahogy vártuk:

• Néha az egységteszt menü összes eleme le volt tiltva. Ilyen esetekben kattintson a menüpontra Nézet → Egységteszt
• A szkripten belüli összes teszt a kontextus beállításának és visszaállításának közös készletét használja, ami meglehetősen logikus. De mivel a teszt fülön keresztül szerkeszthetők, úgy tűnik, hogy minden teszthez külön-külön személyre szabhatók.

Tesztvezérelt fejlesztés

Mielőtt elkezdhetnénk, létre kell hoznunk egy üres eljárást, különben nem lehet tesztet létrehozni. Bár az argumentumlista üresen is hagyható, erre nincs szükség.

Kezdetben feltételezhetjük, hogy egy üzenet elküldéséhez szükségünk lesz egy kliens azonosítóra, feladóra, címzettre, valamint magára az üzenet törzsére. Ezenkívül jeleznünk kell a végrehajtás eredményét, mondjuk egy kimeneti paraméteren keresztül. Az eljárás létrehozása párbeszédpanel segítségével egy meglehetősen megfelelő definíciót kaphat:

ELJÁRÁS LÉTREHOZÁSA VAGY CSERÉJE QUEUE_MESSAGE (V_ID_CLIENT A SZÁMÁBAN, V_SENDER A VARCHAR2-BEN, V_RECIPIENT IN VARCHAR2, V_MESSAGE IN NVARCHAR2, V_IS_QUEUED OUT NUMBER) MINT BEGIN NULL; END QUEUE_MESSAGE;

Az Oracle esetében célszerű előtagot beállítani azokhoz a változókhoz, amelyek neve egybeeshet a mező nevével, mivel kétértelműség esetén a híres DBMS a mező javára oldja meg a vitát. A félreértések elkerülése érdekében egyszerűbb kivétel nélkül minden változót előtagként megadni.

jegyzet

Ha az eljárás paraméterei megváltoztak, akkor minden tesztforgatókönyvét manuálisan kell frissíteni a helyi menü elemre kattintva Teszt szinkronizálása...

Első forgatókönyv

Példánk leegyszerűsítése érdekében tegyük fel, hogy egy üzenet költsége 0,03 pénz. És furcsa módon Gherkin nagyon alkalmas a forgatókönyv leírására:

Adott: Aktív utólagos ügyfél Amikor: Üzenetet küld Ekkor: Pozitív eredményt ad vissza, ÉS az üzenet költsége rögzítésre kerül a tranzakciós naplóban, Ezen kívül az üzenet bekerül a sorba.

A legtöbb gyors út teszt létrehozása – kattintson jobb gombbal egy eljárásra az objektumfában, majd válasszon ki egy menüpontot Egységteszt létrehozása...... A megjelenő ablakban azonnal rákattinthat a gombra Befejez... Forgatókönyv QUEUE_MESSAGE egyetlen teszttel meg kell jelennie a panelen Egységteszt.

A kontextus beállítása

Először is fel kell töltenünk az adatbázist a szükséges adatokkal. Úgy találtuk, hogy a legkényelmesebb a PL / SQL mód használata a kontextus beállításához és visszaállításához. A könyvtárban való közzététellel azonban bármelyik opció könnyen újrafelhasználható. Ha egy meglévő lépést szeretne másolni a könyvtárból, válassza ki azt a legördülő listából, majd kattintson a gombra Másolat... És ha változtatás nélkül, de gomb helyett kell használni Másolat be kell kattintania a jelölőnégyzetre Iratkozz fel.

Gondosan!

Vonzónak tűnhet az ötlet, hogy egy meglévő adatbázist használjunk tesztelésre. Úgy tűnik, hogy elmentette az adatokat a beállításokban, és visszaállította a kontextus visszaállításakor ... Azonban szem előtt kell tartani, hogy ha váratlan hiba történik a tesztek végrehajtása során bármely szakaszban, akkor az adatbázis megjelenik abban a formában, amelyben a hiba idején volt, és a kontextus nem áll vissza. Ezért a legjobb, ha tiszta adatbázist használunk, amely nem ijesztő, és a szerkezet vagy az adatok sérülése esetén könnyen teljesen újra létrehozható.

Feltételezve, hogy üres adatbázissal dolgozunk, csak egy utólagos fizetésű ügyfélrekordot kell beillesztenünk a kontextus beállításához. Elnevezéssel azonnal elmenthető a könyvtárba Utólagos fizetésű ügyfél.

Kontextus visszaállítása

A tesztek újrafuttatásához a hozzáadott adatokat törölni kell. A mi esetünkben azonban egyszerűen törölheti a tesztek által érintett összes táblát. Ezt a lépést is el kell menteni a könyvtárba későbbi használatra.

Hívás

A tényleges tesztvégrehajtást a tárolt eljárás paramétereinek beállítása határozza meg. Itt vannak beállítva az ellenőrzéshez szükséges kimeneti paraméterek értékei is. A kimeneti paraméterek ellenőrzése egy jelölőnégyzet segítségével letiltható Teszteredmény... A táblázatban és dinamikusan beállított paraméterekre vonatkozik.

Gondosan!

Első pillantásra úgy tűnhet, hogy nagyon kényelmes a paraméterek beállítása az egérrel a táblázatban, de szem előtt kell tartani, hogy ez a táblázat nem másolható. Ez különösen fontos a nagy mennyiség argumentumokat, mivel a következő teszt létrehozásához mindegyiket manuálisan újra be kell állítani, különösen akkor, ha új teszt csak egy értékkel tér el a jelenlegitől. A dinamikus értéklekérdezések a táblákkal ellentétben elmenthetők egy könyvtárba, majd újra felhasználhatók vagy másolhatók.

Ahogy fentebb említettük, a dinamikus lekérdezés felhasználóbarátabb. Azt is érdemes megjegyezni, hogy a kérésben a kimeneti paraméterek nevét a név végén egy $ jellel kell kiegészíteni:

válasszon 1-et V_ID_CLIENT-ként, "79052222222"-t V_SENDER-ként, "79161111111"-t V_RECIPIENT-ként, "Menjünk sétálni!" AS V_MESSAGE, 1 mint V_IS_QUEUED $ a DUAL-tól

jegyzet

A dinamikus lekérdezési módból a táblázatos lekérdezési módba való visszatéréshez teljesen törölnie kell a dinamikus lekérdezés értékét.

Mivel megadtuk a kimeneti paraméter ellenőrzését, máris le tudjuk futtatni a szkriptet és látjuk a hibát. Ha minden helyesen történik, a rendszernek hibát kell jelentenie. Minden egyéb hiba ebben a szakaszban helytelen konfigurációt jelent.

A teszt lecsillapításának legegyszerűbb módja, ha az eljárás törzsében a kimeneti paraméterbe pofátlanul 1-et írunk: SELECT 1 INTO IS_QUEUED FROM DUAL;

Állítások

A teszt ismét zöld, de még nem ellenőriztük az összes előfeltételt. Ugyanebben a forgatókönyvben más tesztekkel is tesztelheti őket. Új teszt létrehozása előtt át kell nevezni a meglévőt az alapértelmezett „Tesztvégrehajtás 1”-ről „Pozitív eredmény”-re, a teljes szkriptet pedig „Aktív számlás ügyfél üzenetet küld” névre.

Fontos

Könnyen feltételezhető, hogy minden egyes tesztet egy tranzakción belül hajtanak végre. A gyakorlatban azonban kiderült, hogy ez nem így van. Váratlan hiba esetén az adatbázis határozatlan állapotba kerülhet. Ez a viselkedés nem befolyásolja a várható hibákat.

Következő ellenőrzésünket egy külön tesztben fogjuk elvégezni, hogy finomságot kapjunk Visszacsatolásérdemes azonban emlékezni arra, hogy minden új tesztnél időbe telik a kontextus beállítása és visszaállítása, és minden teszt sikertelenségét egyértelmű üzenet kíséri az okáról. Ebben a forgatókönyvben az ellenőrzéseket különböző tesztekre osztjuk fel, majd a következő forgatókönyvben az összes ellenőrzést egyetlen tesztben egyesítjük.

jegyzet

Az SQL Developer nem teszi lehetővé két teszt egyidejű megtekintését. Ha a fában egy másik tesztre vált, az aktuális tesztet egy új teszt helyettesíti ugyanazon a panelen. Ezenkívül ezt a panelt nem lehet két egymástól függetlenül görgető területre felosztani. Viszont nagyon kényelmes kinyitni forrás eljárásokat párhuzamosan a tesztablakkal, hogy gyorsan navigálhasson a két panel között.

A következő teszt annak ellenőrzése, hogy egy üzenet sorba került-e. Mivel a kontextus beállítása és visszaállítása már meg van adva, használnunk kell egy dinamikus kérést a könyvtárból, és be kell állítanunk az érvényesítés-ellenőrzést. Miután kimásoltuk a dinamikus kérést, úgy tűnhet, hogy nem kell ellenőrizni egy már ellenőrzött kimeneti paramétert, és visszaállíthatja a jelölőnégyzetet Teszteredmény... Ha azonban ebben az állapotban futtatja a teszteket, látni fogja, hogy az egyik tesztet figyelmen kívül hagyták. Számomra személy szerint a figyelmen kívül hagyott teszt a befejezetlen munka szimbóluma, ezért a jelölőnégyzetet a helyére kell tenni.

Számos módja van az állítások igazolásának. A lista első eleme egy logikai függvény. Alkotás közben logikai függvény, a párbeszédablak tökéletesen megfelelő sablont biztosít:

- Cserélje ki ezt a kódot egy logikai értékre - ehhez hasonló kifejezés: - RETURN FALSE; - vagy egy kódblokk, amely logikai értéket ad vissza - hasonlóan a következőkhöz: DECLARE l_count NUMBER; BEGIN SELECT count (*) INTO l_count FROM dual; HA l_count<>0 THEN RETURN TRUE; ELSE RETURN HAMIS; VÉGE HA; VÉGE;

Ellenőrzésünkhöz ezt a mintát használhatjuk úgy, hogy a dual helyett MESSAGE_QUEUE, majd alkalmazzuk a szükséges szűrőket. A feltételt is módosítani kell az l_count értékről<>0-tól l_count = 1-ig a pontosság érdekében. Ezt követően biztonságosan elmentheti a függvényt a könyvtárba későbbi használatra.

jegyzet

A könyvtárban lévő összes rekord típusának megfelelően mentésre kerül. Ez azt jelenti, hogy ha a jövőben használnia kell például az állításellenőrzést, akkor nemcsak a nevét, hanem a típusát is meg kell jegyeznie. Ez nagyon gyorsan nagyon kényelmetlen lehet, különösen nagy projektek esetén.

A tesztek futtatásakor hibát kell látnunk. Nagyon könnyű megjavítani:

BEHELYEZÉS AZ ÜZENET_VÁRBA (ID_CLIENT, FELADÓ, CÍMZÉS, ÜZENET) ÉRTÉKEK (V_ID_CLIENT, V_SENDER, V_RECIPIENT, V_MESSAGE);

Most már biztos lehet benne, hogy minden teszt sikeresen lezajlott.

jegyzet

A tesztekkel végzett munka során a tároló blokkolva van, így a munka befejezése után vagy be kell zárni az SQL Developert, vagy be kell zárni a lerakat (Deselect Repository).

És végül nézzük meg a tranzakciós nyilvántartást. Ehhez a következő érvényesítési típust választjuk – a Lekérdezési eredmények összehasonlítása. Ahogy a neve is sugallja, nagyon egyszerűen működik: meg kell adni két lekérdezést, amelyek eredménye megegyezik. Mivel a pontos dátumot és időt nem lehet megtudni, 10 másodpercen belül bármilyen értékkel megelégedhet:

- Forráslekérdezés SELECT 1 AS ID_CLIENT, 0,03 AS SUM_VALUE FROM DUAL - Céllekérdezés SELECT ID_CLIENT, SUM (ÉRTÉK) A TRANSZAKCIÓKBÓL, AHOL TRANSACTION_TIME AZ AKTUÁLIS_IDŐBÉLYEG ÉS (CURRENT_TIMESTAMP AZONOSÍTÓ 1/24Y KÖZÖTT);

A tesztek futtatása után homályos érvényesítési hibát látunk, egy nemrégiben történt tranzakció: A lekérdezési eredmények összehasonlítása ellenőrzés eltéréseket talált. Ahol az „egy legutóbbi tranzakció” az utolsó csekk neve a könyvtárban. Bár ez a lehetőség már most is értékes eszköz, jó lenne, ha pontosan megmutatná, miben térnek el az eredmények.

Adjuk hozzá a szükséges funkcionalitást az eljárásunkhoz:

INSERT INTO TRANSACTIONS (ID_CLIENT, VALUE) ÉRTÉKEK (V_ID_CLIENT, 0,03);

Hibakeresés

A tesztek ismételt futtatása után hirtelen kiderül, hogy a hiba nem tűnt el sehova. Valószínűleg már észrevetted a hibát a fenti kódban, de a valós élethelyzetek sokkal bonyolultabbak lehetnek. Mivel az eszköz nem mutatja a különbséget, manuálisan kell kiderítenie az okot. Sajnos az SQL Developer hibakeresési funkciója itt nem tud segíteni. Ez azt jelenti, hogy a tesztet alaphelyzetbe állítás nélkül kell futtatnunk. Ehhez létrehozhat még egy szkriptet - egy hibakeresőt. Vagy inkább kettő: egy - alaphelyzetbe állítás nélkül, de ugyanazzal a dinamikus kéréssel, mint egy nem működő tesztben - annak érdekében, hogy kitaláljuk, mi a hiba; a második pedig - a kontextus beállítása nélkül, de visszaállítással - az első utáni eltávolítás érdekében.

Az első szkript futtatása után megtekintheti a tábla tartalmát, és ellenőrizheti az ellenőrző lekérdezést. Most már jól látható, hogy a probléma pontosan az ellenőrzési kérelemben volt. Nem felejtve el futtatni a második szkriptet az adatok törléséhez, javítjuk a tesztkörülményeket, és megszervezzük az újrafutást. Most már minden rendben van. A hibakereső szkriptek megőrizhetők későbbi hivatkozás céljából, és az első elkészült szkript elhelyezhető egy új tesztcsomagban.

Második forgatókönyv

Most, hogy van egy szkriptünk az üzenet sikeres elküldéséhez, megpróbálhatunk egy szkriptet egy sikertelen üzenethez. Például, ha az utólagos fizetésű ügyfél inaktív:

Adott: Inaktív utólagos ügyfél Mikor: Üzenetet küld Aztán: Visszatér negatív eredmény, és a tranzakció nincs véglegesítve, és az üzenetsor változatlan marad.

Új forgatókönyvet kell készíteni. A kontextus beállítását és a dinamikus lekérdezést is módosítanunk kell egy kicsit, de ez sokkal egyszerűbb, mint a semmiből újakat létrehozni.

A kontextus beállításához másolja ki az "Aktív utólagos ügyfél" PL / SQL lépést, amelyben az 1-et 0-ra cseréljük, és "Inaktív utólagos ügyfél" néven tesszük közzé a könyvtárban. Ugyanezt megismételjük egy dinamikus kérésnél, az új kérést "Elküldetlen üzenet"-nek nevezzük. A kontextus visszaállításához a meglévő lépést használjuk.

Futtatás után a tesztnek hibát kell mutatnia. Nagyon könnyű megjavítani. Cserélje ki a SELECT 1 INTO V_IS_QUEUED FROM DUAL mezőt a SELECT IS_ACTIVE INTO V_IS_QUEUED FROM CLIENTS WHERE ID = V_ID_CLIENT értékre - és minden újra működik.

Ezután ellenőriznie kell, hogy a tranzakció nincs-e elmentve. Ehhez a következő típusú ellenőrzést használjuk - Táblázatok összehasonlítása. Elsőre úgy tűnhet, hogy nincs mihez hasonlítani, de a kontextus meghatározásában lehetőség nyílik másolásra meglévő táblázat ideiglenesen. Ez nekünk megfelelő - a tranzakciókat átmásolhatja egy ideiglenes táblába, és az eljárás meghívása után összehasonlíthatja az eredményeket. A legfontosabb dolog az, hogy ne felejtse el törölni ezt a táblát a kontextus visszaállításakor. Két lehetőség van: visszaállítás, törlés és egyszerűen törlés. Mivel nincs mit visszaállítani, a második lehetőséget választjuk. Vegye figyelembe, hogy a lekérdezések összehasonlításához hasonlóan csak az a visszajelzés, hogy van-e egyezés vagy sem.

Miután a tesztek lefutása után megcsodálta a hibát, elgondolkodhat a megoldáson. Például becsomagolhatja a beszúrást egy állapotba a frissen frissített V_IS_QUEUED használatával:

HA V_IS_QUEUED = 1, AKKOR BEHELYEZZE A TRANZAKCIÓKBA (ID_CLIENT, ÉRTÉK) ÉRTÉKEKET (V_ID_CLIENT, 0,03); VÉGE HA;

Összeállítjuk az eljárást, lefuttatjuk a teszteket - minden működik.

Végül ellenőriznünk kell, hogy az üzenetsor nem változott-e. És bár viszketés lett volna azonnal a feltételen belül a tranzakciós betét mellé tenni az üzenetbetétet, ez jutalom lenne a fegyelem megszegéséért. Ezért először létrehozunk egy további ellenőrzést ehhez az állításhoz. A következő típusú ellenőrzés a lekérdezés, amely nem ad vissza sorokat. Mivel minden teszt után teljesen törlünk minden adatot, elég lesz a SELECT * FROM MESSAGE_QUEUE lekérdezésként megadni.

A próbaüzem hibát mutat, amit a betét feltételen belüli elhelyezésével könnyen kijavíthatunk. És itt ér véget a második forgatókönyvünk.

következtetéseket

Az SQL Developer használható tárolt eljárások fejlesztésére a TDD módszerrel. Számos hátránya ellenére ez a csomag platformot biztosít a tárolt eljárások fejlesztéséhez, lehetővé téve a fejlesztők számára, hogy egyszerűen és magabiztosan módosítsák és bővítsék a meglévő eljárások funkcionalitását.

Sajnos a teszttárat csak ben lehet létrehozni Oracle DBMS... Ezenkívül a harmadik féltől származó DBMS-ek, például a PostgreSQL vagy akár a MySQL tesztelési adatbázisként való használatára tett kísérletek a tesztelési alrendszer meghibásodásával végződnek. Az is kiderült SQL használatával A folyamatos integrációs rendszerek fejlesztője sok problémát okoz, de ez egy másik történet.

és EXEC SP () és CALL SP () használható az SQL * Plusban az SP végrehajtására. Egyébként használhatod a BEGIN SP (); VÉGE;

de vannak különbségek.

A CALL az Oracle SQL, és mindenhol működnie kell. Az Oracle-lel kommunikáló egyéb DB-kliensek támogathatják vagy nem támogatják az SQL * Plus EXEC-et. Sokan (pl. Oracle SQL Developer, SQLWorkbench / J), de néhányan nem (Liquibase).

az átadott paraméterek adattípusait a CALL utasításnak kell lennie SQL típusok adat. Nem csak PL / SQL adattípusok, például BOOLEAN.

Az EXEC nem csak SP, hanem tetszőleges utasítás végrehajtására is használható.

ha az SP-nek nincsenek paraméterei, használhatja az EXEC SP-t; szintaxis, de a CALL üres zárójeleket igényel: CALL SP ();

Ha a sys_refcursort visszaadó procit a Toad segítségével hívja meg, különbség van a CALL és az EXEC között.

foo eljárás létrehozása (i in number, o out sys_refcursor) hogyan indítható el a open for select i from dual; vége;

exec foo (1,: r); - 1 sort ad ki

call foo (1 ,: r); - 0 sort ad ki

Megjegyzés: ha egy paraméter elé kettőspontot tesz, a varangy kéri a típust (ez ebben az esetben a kurzor).

Az EXECUTE paraméterként egy karakterláncot vesz fel, amely lehetővé teszi a dinamikus sql "végrehajtását". Futtatás alapvetően mondjuk ... ezzel a bemeneti karakterlánccal futtassa az SQL motort a tartalomra.

a hívás átadja a vezérlést egy tárolt eljárásnak vagy modulnak.

Mint látható, fogalmilag teljesen különböznek egymástól. Ha azonban csak követi az eljárást, a gyakorlatban ezek a használati esetek ugyanazok.

Úgy gondolom, hogy az egyértelmű kód érdekében, ha nem kell végrehajtania, használjon hívást.

P. 19-1

19. fejezet

Szoftvermodulok írása

Ez a fejezet elmagyarázza, hogyan hozhat létre felhasználónevű rutinokat (PL/SQL-eljárásokat és függvényeket), amelyeket aztán meghívhat triggerekből és más, űrlapmodulokban, menükben és könyvtárakban lévő felhasználónevű rutinokból. A következő témákat tartalmazza:

A 19–2. felhasználói név szubrutinokról

Hozzon létre egy szubrutint 19-3 felhasználónévvel

Alprogramok hívása 19-7 felhasználónévvel

A 19-8 paraméterek meghatározása

PL / SQL csomagok 19-10

P. 19-2

A felhasználónév szubrutinokról

Alprogram felhasználónévvel egy nevű PL / SQL függvény vagy eljárás, amelyet űrlapmodulba, menübe vagy könyvtárba írhat. Bár a hozzáadás elsődleges módja programvezérlés Az Oracle Forms-ban az alkalmazások triggerek, a felhasználónév-rutinok kibővítik a triggereket, lehetővé téve a program újrafelhasználását anélkül, hogy újra be kellene írnia több triggerbe.

Az alkalmazáseseményekre válaszul végrehajtott triggerekkel ellentétben a felhasználónév szubrutinokat kifejezetten meg kell hívni az alkalmazásban. Az űrlapmodulban megadott felhasználónév-szubrutin a modul bármely triggeréből hívható.

Ahogyan a beágyazott rutinok megkímélik az olyan gyakori funkciókhoz, mint például a navigáció és az adatbázis-interakció programjainak írásától, a felhasználónév-rutinok lehetőséget biztosítanak az egyes konkrét funkciók újrafelhasználására. alkalmazási program azt a programot, amit maga írt.

Ha azon kapja magát, hogy ugyanazt a kódsort egynél több triggerben vagy menüelemben írja le, akkor érdemes inkább egy felhasználónév szubrutin írását megfontolni.

A legtöbb alkalmazási programban a kezelők ugyanazokat a műveleteket több módon és több ablakból vagy menüből is végrehajthatják. Például egy rendelésbeviteli alkalmazás lehetővé teheti a kezelő számára, hogy egy billentyű lenyomásával, egy gombra kattintással vagy egy menüelem kiválasztásával kiszámítsa a rendelések összességét. A felhasználónév szubrutin nélkül ugyanazt a számítási képletet kellene beírni a Key trigger, a When-Button-Pressed trigger és a menüelem parancsba.

Jobb, ha egyszer beírod a számítási képletet egy felhasználói névvel ellátott szubrutinba. Mondjuk ennek a rutinnak értelmes nevet adhatsz számítás_összegek, majd nevén hívja bármely triggerből vagy menüelemből, amelyhez ez a képlet szükséges.

A beépített rutinokhoz hasonlóan a felhasználónevű rutinok is paramétereket vehetnek fel. Amikor deklarál egy rutin paramétereit, meg kell adni az adattípust, a módot és az alapértelmezett értékeket, ha vannak ilyenek. Ha paramétereket használ a tényleges értékek átadására, akkor általánosabb rutinokat hozhat létre, amelyek a futás közben programozottan megadott értékeket használják.

P. 19-3

Alprogramok létrehozása felhasználónévvel

A felhasználónevű rutinok elnevezett objektumok, amelyeket egy űrlap, menü vagy könyvtár moduljaiban határozhat meg.

Felhasználónévvel rendelkező szubrutin létrehozása:

A Navigátorban válassza ki a kívánt Programegységek csomópontot, majd válassza a Navigátor-> Létrehozás lehetőséget.

Megjelenik az Új programegység párbeszédpanel.

A PL / SQL-szerkesztő parancsaival kapcsolatos információkért lásd a 2. fejezetet, „A tervezőeszközök használata”.

Létrehozásához adja meg a kódegység nevét, majd határozza meg a típusát (eljárás, funkció, csomagspecifikáció vagy csomagtörzs).

Írja be, szerkessze és fordítsa le az Ön által meghatározott eljárást vagy függvényt.

Írja be egy eljárás vagy függvény teljes definícióját szabványos PL / SQL struktúra és szintaxis használatával. További információkért tekintse meg a fejezet későbbi részében az „Eljárás szintaxis” és „Funkció szintaxis” című részt.

A programegység összeállításához válassza a Fordítás lehetőséget.

jegyzet: Az Oracle Forms automatikusan alkalmazza a változtatásokat a szerkesztő bezárásakor, még akkor is, ha nem sikerült lefordítania a kódmodult.

Az Oracle Forms kiírja az egyes programegységek nevét a típusukat jelző megjegyzéssel (eljárástörzs, csomagspecifikáció stb.). Például az eljárás törzse a következőképpen lesz jelölve:

kalkulációs_összegek (eljárás törzse)

A csomag specifikációja pedig így nézne ki:

Hibakezelők (csomagspecifikáció)

P. 19-4

Eljárás szintaxis

LeírásAz eljárások a PROCEDURE kulcsszóval kezdődik, és az eljárás nevével vagy formális paraméterlistájával végződik. Test egy eljárás az IS kulcsszóval kezdődik és az END kulcsszóval végződik, amelyet az eljárás opcionális neve követ.

Szintaxis:

PROCEDURE eljárás_neve IS

KEZDŐDIK

nyilatkozatok

VÉGE;

ahol:

eljárás_neve	Az eljárás egyedi, felhasználó által meghatározott neve. Ennek a névnek meg kell felelnie az ORACLE elnevezési konvencióknak. További információ megtalálod benne SQL nyelvi kézikönyv.
érvlista	ahol:
var_name
mód	Ez (!! alatt !! IN | OUT | IN OUT).
típus
érték	PL / SQL kifejezés.
helyi_változó_deklaráció
nyilatkozatok
kivétel_kezelő	Beszélni valakihez .

P. 19-5

Függvény szintaxis

Minden függvénynek végre kell hajtania egy RETURN utasítást. A RETURN utasítás beállítja a függvény visszatérési értékét, és azonnal visszaadja a vezérlést ahhoz a triggerhez, felhasználónév szubrutinhoz vagy menüelem parancshoz, amelyből a függvényt meghívták.

Szintaxis:

FUNCTION függvény_neve IS

KEZDŐDIK

nyilatkozatok

VISSZATÉRÉS (eredmény);

VISSZATÉRÉS (eredmény);

VÉGE;

ahol:

függvény_neve	A függvény egyedi, felhasználó által meghatározott neve. Ennek a névnek meg kell felelnie az ORACLE elnevezési konvencióknak.
érvlista	Ez ((var_nametype [: = érték]) [, ...]) ahol:
var_name	A helyi változó egyedi neve.
mód	Ez (IN | OUT | IN OUT).
típus	Ez )(,...)]
nyilatkozatok	Futtatható PL / SQL utasítások.
kivétel_kezelő	Beszélni valakihez PL / SQL felhasználói kézikönyv és referencia.
eredmény	Egy függvény értékét jelölő kifejezés. A kifejezés értékének kompatibilisnek kell lennie a függvényspecifikációban megadott típussal.

P. 19-6

Példa eljárás:

A következő eljárás a rendelést egy adott cikk készletének csökkentésével dolgozza fel. Az eljárás lehívásához át kell adnia a cikkazonosítót, a megrendelt egységek számát és azt a raktárt, amelynek ki kell töltenie ezt a rendelést:

ELJÁRÁS do_order (az egységek_sorrendje: SZÁM,

prod_id IN NUMBER,

raktár SZÁMÁBAN) IS

egységek_készleten_NUMBER;

KEZDŐDIK

SELECT mennyiség_készleten INTO egység_készleten_készlet A készletből

WHERE termék_azonosító = prod_id

ÉS raktárazonosító = raktár;

IF units_in_stock> = egységek_készleten - units_ordered THEN

készlet FRISSÍTÉSE

SET_in_stock = egységek_készletben - egységek_rendezett

WHERE termék_azonosító = prod_id;

MÁS

Üzenet ("Elégtelen készlet")

RAISE Form_Trigger_Failure;

VÉGE HA;

VÉGE;

Ezt az eljárást a következőhöz hasonló triggerben használhatja:

do_order (: order.units,: order.prod_id,: raktár.azonosító);

Ebben a példában a három formális paraméter értéke az űrlap elemeinek aktuális értéke, amelyet a szabványos kötési változó szintaxisa határoz meg:

: blokk_neve.elem_neve

Példa a függvényre:

A következő függvény a raktáron lévő cikkek számát adja vissza egy adott raktárban. A függvény meghívásakor átadja a cikkazonosítót és a raktárazonosítót:

FUNCTION get_inventory (sz. termék, NUMBER. raktár)

VISSZATÉRÉSI SZÁM IS

összeg SZÁM;

KEZDŐDIK

KIVÁLASZTÁSA készleten lévő mennyiség INTO mennyiség A készletből

WHERE termék_azonosító = termék és raktárazonosító = raktár;

RETURN összeg;

KIVÉTEL

AMIKOR MÁSOK AKKOR

Üzenet ('Rossz terméknév vagy raktárazonosító');

VISSZATÉRÉS (-1);

VÉGE;

P. 19-7

Ezt a funkciót az alábbi triggerben használhatja:

KIJELENT

invNUMBER;

szükséges_összegSZÁM: =: rendelési_blokk.rendelési_tétel;

KEZDŐDIK

inv: = Készlet lekérése (: termékazonosító,: raktár.azonosító);

HA bev< 0 THEN

Itt van a hibakezelés

ELSE IF inv> = szükséges_összeg AKKOR

Megrendelés feldolgozása itt

VÉGE HA;

VÉGE;

Alprogramok hívása felhasználónévvel

Az eljárások és függvények felhasználónévvel történő hívása hasonló a beépített eljárások és függvények hívásához; névleges és pozíciós kötéseket is használhat a paraméterek átadásához. A felhasználónév-szubrutinokban pontosan úgy érheti el az űrlapobjektumokat, mint a beépített szubrutinokban lévő paraméterlisták esetében.

Amikor űrlapot vagy menümodult hoz létre egy végrehajtható fájl létrehozásához, az Oracle Formsnak képesnek kell lennie megtalálni a modul által meghívott szubrutinokat. A szubrutin honnan hívható, azt a modul jelzi, amelyben definiálva van.

Ha egynél több modult tartalmazó alkalmazást fejleszt, vegye figyelembe a következő hatóköri szabályokat:

· egy űrlapmodulban definiált felhasználónévvel rendelkező szubrutin csak triggerekből és más, ugyanabban a modulban lévő felhasználónévvel rendelkező szubrutinokból hívható meg

· menümodulban meghatározott felhasználónévvel rendelkező szubrutin csak ugyanabban a modulban található menüpontból és indítóparancsokból hívható meg

· egy könyvtár modulban meghatározott felhasználónévvel rendelkező szubrutin egy menüelem bármely triggeréből vagy parancsából hívható, feltéve, hogy ez a könyvtár csatlakozik egy űrlap- vagy menümodulhoz

P. 19-8

Nem hozható létre felhasználónevű rutinok könyvtára úgy, hogy eljárásokat és függvényeket ír közvetlenül a könyvtármodulba, vagy más modulokból másolja be a rutinok könyvtárába. A könyvtárral kapcsolatos információkért lásd a 20. fejezetet, „Munka a könyvtárakkal”.

Paraméter definíció

A paraméterek használata nem kötelező. A paramétereket nem igénylő szubrutinokat zárójelek nélkül írjuk. Ha deklarál egy paramétert, akkor a paraméterlistában meg kell adni az adattípust és módot.

Paraméter adattípusok A paraméterek deklarálhatók VARCHAR2, DATE, NUMBER vagy BOOLEAN típusúként, vagy bármilyen típusú Oracle Forms objektumként. Függvény vagy eljárás létrehozásakor minden formális paraméter neve után adja meg az adattípust:

ELJÁRÁS megjelenítési_lejárt_küldemények (részleg_azonosító SZÁM);

FUNCTION credit_ok (ügyfél VARCHAR2) RETURN BOOLEAN;

Paraméter módok A paraméter mód lehet IN (alapértelmezett), OUT vagy IN OUT. Az IN paraméter átadja az értéket az alprogramnak. Az alprogram ki tudja olvasni az IN paraméter értékét, de nem tudja írni az értékét. Az érvényes IN paraméter lehet konstans, literális, inicializált változó vagy kifejezés.

Az OUT paraméter az alprogram értékeit adja vissza. Az aktuális OUT paraméter lehet egy helyi változó (nem csatlakoztatva), és az alprogramnak értéket kell hozzárendelnie ehhez a változóhoz. Ha nem, akkor az előre meghatározott PL / SQL kivétel NO_DATA_FOUND fog megjelenni.

Az IN OUT paraméter átadja az értéket az alprogramnak, és visszaadja az értéket az alprogramból. Az érvényes IN OUT paraméter lehet helyi változó vagy kötési változó. A szubrutin kiírhatja az IN OUT paraméter értékét, de nem muszáj.

Mind a funkciók, mind az eljárások fogadhatnak OUT és IN OUT paramétereket. Az OUT vagy IN OUT paraméteren keresztül értéket visszaadó eljárás ugyanúgy működik, mint egy függvény, és minden olyan esetben használható, amikor a függvényeket gyakran használják.

Ha egy eljárás vagy függvény specifikációjában nem jelzi kifejezetten egy formális paraméter módját, akkor ez a paraméter IN paraméterként lesz deklarálva. Így a következő eljárási specifikációk egyenértékűek:

ELJÁRÁS kalkulációs_kedvezmény (SZÁM szorzó);

ELJÁRÁS kalkulációs_kedvezmény (szorzó SZÁMBAN);

P. 19-9

Explicit módon beállíthatja egy paraméter módját, ha beírja az IN, OUT vagy IN OUT parancsot a formális paraméter neve után az alprogram specifikációjában.

jegyzet: IN OUT vagy OUT paramétert felvevő szubrutin hívásakor ügyeljen arra, hogy egy érvényes paraméterhez mindig hozzárendelnek értéket, még akkor is, ha maga az alprogram nem írja ki kifejezetten az adott paraméter értékét.

Ha például egy szövegelemre hivatkozik az IN OUT formális paraméter érvényes paramétereként, akkor az adott elem értéke az alprogram végrehajtása után frissül, még akkor is, ha maga az alprogram nem hajtja végre az explicit hozzárendelési utasítást. Ez azt eredményezheti, hogy a rekord állapota MÓDOSÍTOTT állapotra változik, és megjelöli a rekordot frissítésre vagy beszúrásra.

Alapértelmezett értékek hozzárendelése az IN paraméterekhez A formális IN paraméterhez alapértelmezett értéket rendelhet a paraméter deklarálásakor. Az Oracle Forms beépített rutinjai közül sok használja ezt a technológiát. Az ilyen rutinok meghívásakor nem kell érvényes paramétert megadnia az alapértelmezett formális paraméterhez, hacsak nem szeretné felülírni az alapértelmezett paraméterértéket.

Ha egy formális paraméterhez alapértelmezett értéket szeretne rendelni, használja a PL / SQL hozzárendelési utasítást a formális paraméterlistában. A hozzárendelt értéknek a formális paraméterrel azonos típusú konstansnak vagy kifejezésnek kell lennie:

ELJÁRÁS kiszámítja_kedvezmény (szorzó SZÁMBAN: = 15);

Ennek az eljárásnak a meghívásával paraméterezhető szorzó hagyja ki, ha azt szeretné, hogy az eljárás az alapértelmezett értékkel (15) történjen:

kalkulál_kedvezmény;

Vagy felülírhatja az alapértelmezett értéket egy érvényes paraméter megadásával:

kalkulál_kedvezmény (10);

Vegye figyelembe, hogy a referencia jelölő használatakor csak az utolsó paraméterek lehetnek alapértelmezettek.

P. 19-10

PL / SQL csomagok

A csomag egy PL / SQL konstrukció, amely logikailag kapcsolódó típusokat, objektumokat, eljárásokat és függvényeket csoportosít. A csomagok általában két részből állnak, egy specifikációból és egy törzsből, bár néha nincs szükség testre.

A specifikáció egy interfész a csomaghoz; deklarálja a használható típusokat, változókat, konstansokat, kivételeket, kurzorokat és alprogramokat (eljárásokat és függvényeket). A törzs teljesen definiálja a kurzorokat és az alprogramokat, és így érvényesíti a specifikációt.

Az Oracle Forms számos előre definiált csomagot biztosít a használatra, vagy megadhatja saját csomagjait űrlap-, menü- vagy könyvtármodulokban. Csomagokat is definiálhat az Oracle7Serverben, majd a tartalmukat ügyféloldali alkalmazásokból érheti el. Az Oracle Forms tárolt eljárások használatával kapcsolatos információkért lásd a 2. fejezetet, „Tárolt eljárások és adatbázis-indítók” Oracle Forms Advanced Techniques kézikönyv.

A csomag szintaxisa hasonló az eljáráshoz:

CSOMAG neve IS - specifikáció

Általános és objektumtípus-nyilatkozatok

Rutin specifikációk

VÉGE;

A CSOMAG TESTNEVE IS - test (rejtett rész)

Nyilvános és tárgyi nyilatkozatok

Szubrutin testek

VÉGE;

A specifikáció általános deklarációkat tartalmaz, amelyek láthatók az alkalmazás számára. A törzs végrehajtási részleteket és privát nyilatkozatokat tartalmaz, amelyek rejtve vannak az alkalmazásban.

Csak a csomagspecifikációban szereplő nyilatkozatok láthatók és érhetők el az alkalmazás számára. A végrehajtási részletek a csomagtörzsben rejtettek és nem érhetők el. A specifikáció külön programozható és összeállítható. Miután összeállította a BOM-ot, sikeresen lefordíthatja az összes felhasználónév-triggert és szubrutint, amelyre az anyagjegyzék hivatkozik. Nem kell teljesen meghatároznia a csomag törzsét, amíg nem áll készen az alkalmazás leállítására.

Csak a szubrutinoknak és kurzoroknak van rejtett végrehajtása és meghatározása. Ezért, ha a specifikáció csak típusokat, konstansokat, változókat és kifejezéseket deklarál, akkor a csomag törzse nem kötelező.

P. 19-11

Csomag készítés

Csomagokat hozhat létre úgy, hogy eljárásait és funkcióit PL / SQL objektumok bőröndjévé szervezi.

A csomagok tartalmazhatnak olyan változókat, amelyek állandóak a teljes felhasználói munkamenetben (hasonlóan a GLOBAL változóhoz, és ugyanolyan hasznosak a szerver oldalon), valamint olyan kurzorokat, amelyek nyitva maradhatnak a csomagban lévő függvények és eljárások meghívására.

A csomagokkal kapcsolatos további információkért lásd a PL / SQL 2.0-s verzióját Felhasználói kézikönyv és referencia.

Példa:

A LIB_HR AS CSOMAG LÉTREHOZÁSA VAGY CSERÉJE

FUNKCIÓ get_ssn (az EmpNo NUMBER) VISSZA SZÁM;

Új munkatársat felveszünk és a személyi számát visszaküldjük

a SZÁMOS osztály,

theSalNUMBER,

theDate DATE,

theSSNNUMBER) VISSZASZÁM;

theReason VARCHAR2);

A prémium változó beállítása

PROCEDURE set_bonus (newValue NUMBER);

VÉGE LIB_HR;

CSOMAG LÉTREHOZÁSA VAGY CSERÉJE LIB_HR AS

A csomag változói -

aláírási bónusz SZÁMA: = 1000;

Csomag kurzor -

CURSOR next_empid

IS SELECT empid_sequence.NEXTVAL

kettős;

A munkavállaló társadalombiztosítási számának lekérése

FUNKCIÓ get_ssn (az EmpNo NUMBER) VISSZATÉRÉSI SZÁM IS

tmpSSN SZÁM;

P. 19-12

KEZDŐDIK

SELECT ssn

A tmpSSN-be

FROM emp

WHERE empno = theEmpNo;

RETURN (tmpSSN);

KIVÉTEL

AMIKOR NINCS_ADATOK AKKOR

VISSZATÉRÉS (-1);

VÉGE;

Új alkalmazottat veszünk fel, és visszaküldjük a létszámot

FUNCTION hire_employee (a név VARCHAR2,

a SZÁMOS osztály,

theSalNUMBER,

theDate DATE,

theSSNNUMBER) VISSZATÉRÉSI SZÁM IS

tmpEmpNo NUMBER;

KEZDŐDIK

IF (NEM next_empid% ISOPEN) THEN

OPEN next_empid;

VÉGE HA;

FETCH next_empid INTO tmpEmpNo;

Nem kell bezárnunk a kurzort, mert az lesz

Legyen nyitott a hívások között

INSERT INTO EMP (empno, ename, deptno, sal,

bérelt, ssn, bónusz)

ÉRTÉKEK (tmpEmpNo, theName, theDept, theSal,

theDate, theSSN, signingBonus);

RETURN (tmpEmpNo);

KIVÉTEL

AMIKOR MÁSOK AKKOR

VISSZATÉRÉS (-1);

VÉGE;

Meglévő alkalmazott elbocsátása

ELJÁRÁS fire_employee (the Empno NUMBER,

az ok VARCHAR2) IS

KEZDŐDIK

TÖRLÉS EMP

WHERE empno = theEmpno;

INSERT INTO megszűnések (empno, oka)

ÉRTÉKEK (az Empno, az Ok);

VÉGE;

P. 19-13

A prémium változó beállítása

ELJÁRÁS set_bonus (newValue NUMBER) IS

KEZDŐDIK

signingBonus: = newValue;

VÉGE;

VÉGE LIB_HR;

jegyzet: Amikor egy csomagot először hív meg (a példány bármely felhasználója), a teljes csomag betöltődik az Oracle7 SGA-ba, amely nagyon gyorsan hívja meg a benne lévő eljárásokat és funkciókat.

KorlátozásokAz Oracle Forms közvetlen támogatást nyújt a tárolt eljárások és függvények hívásához, de nem közvetlenül hozzáférhet a csomagváltozókhoz vagy kurzorokhoz. A csomagváltozók és kurzorok kiszolgálóoldali programokon belüli manipulálásához létre kell hoznia egy eljárást vagy függvényt. Az érvényes adattípusok a következők:

VARCHAR2 – maximum VARCHAR2 (2000)

SZÁM

DÁTUM

BOOL

Ha ezeket az adattípusokat használja eljárások és függvények írásához, akkor a csomagváltozók értékei és a visszakeresett kurzoradatok paramétereken vagy függvényértékeken keresztül visszaküldhetők az Oracle Forms hívónak.

Az Oracle Forms megköveteli, hogy a specifikáció és a csomagtörzs érvényes legyen a csomaghoz hozzáférő Oracle Forms PL/SQL blokk lefordításához.

Hozzáférés egy csomag tartalmához

A csomag tartalmára a szabványos PL / SQL pontjelöléssel hivatkozhat:

csomag_neve.objektum_neve

csomag_neve.program_egység_neve

Például eljárást hívni arrange_windows a csomagban van meghatározva win_manage, a következőket írhatja be egy triggerbe vagy egy szubrutinba egy felhasználónévvel:

win_manage.arrange_windows

Ugyanezek a hatóköri szabályok vonatkoznak azokra a csomagokra, amelyek felhasználónévvel rendelkező rutinokra hivatkoznak.

P. 19-14

Oracle Forms csomagok

Az Oracle Forms a következő előre meghatározott csomagokat biztosítja:

Szabványos bővítmények	A STANDARD Extensions csomag beépített Oracle Forms funkciókat és eljárásokat tartalmaz.
TOOL_ENV	A TOOL_ENV csomag lehetővé teszi az Oracle környezeti változóival való interakciót.
ORA_NLS	Az ORA_NLS csomag lehetővé teszi az információk kinyerését magas szint a nyelvi környezetedről.
TOOL_RES	A TOOL_RES csomag lehetővé teszi a láncolt erőforrások kibontását egy erőforrásfájlból.
ORA_FFI	Az ORA_FFI csomag lehetővé teszi a hozzáférést külső funkciók(3GL).
ORA_DE	Az ORA_DE csomag egy belső csomag. Ne használja ezt a csomagot.
STPROC	Az STPROC csomag egy belső csomag. Ne használja ezt a csomagot.
TEXT_IO
PECS	A PECS csomag lehetővé teszi egy űrlap teljesítményének értékelését.
FORMS_OLE	A FORMS_OLE csomag Oracle Forms OLE függvényeket és eljárásokat tartalmaz.
	A VBX csomag Oracle Forms VBX függvényeket és eljárásokat tartalmaz.
Alapértelmezett	A Standard csomag PL / SQL függvényeket és eljárásokat tartalmaz.