 |
|
|
 | Aplikace | Export a šíření aplikace |  |
Pro pohodlný návrh jednotlivých součástí aplikace - tabulek, dotazů, domén, sekvencí, transportů, diagramů - 602SQL obsahuje interaktivní návrháře. Pro psaní procedur a triggerů je k dispozici textový editor integrovaný s ostatními prvky vývojového prostředí.
Veškeré objekty vytvářené pomocí vývojového prostředí lze validovat (ověřit jejich syntaktickou správnost). Procedury uložené na serveru a triggery lze také ladit pomocí debuggeru a profilovat pomocí interního profileru.
Pro spouštění SQL příkazů zadaných ad-hoc je v k dispozici okno SQL konzole. Pro testovací spouštění procedur z řídicího panelu slouží nástroj, dovolující zadat vstupní parametry a po provedení zobrazit výstupní parametry.
Pro ladění slouží také logy, které si vývojář může definovat podle potřeby a trasovat v nich specifické situace nebo operace s vybranými objekty. Logy a jejich obsah se definují na záložce Trasování v okně Monitor. Zde lze také sledovat a řídit mnohé činnosti serveru.
Během vývoje databázové aplikace dochází v její komponentách k mnoha změnám a dočasně vznikají nekonzistence. Pokud je například v návrhu tabulky odstraněn sloupec a přidán jiný sloupec, pak s touto tabulkou nejsou konzistentní dotazy, které s odstraněným sloupcem pracovaly, do té doby, než je jejich návrh opraven.
Striktní dodržování norem SQL by vyžadovalo zrušení všech objektů, v nichž vznikne nekonzistence. 602SQL dovoluje, aby v průběhu vývoje nekonzistence dočasně existovaly. Obsahuje nástroje, které nekonzistence odhalují a upozorňují na ně.
Z vývojového prostředí lze příkazem Kontrola syntaxe z popup menu u aplikace spustit syntaktickou kontrolu všech objektů ve schématu. Do okna Výstupy se zapíšou všechny objekty, v nichž je odhalena chyba.
Databázové tabulky lze během vývoje používat i tehdy, když se vyskytuje chyba v implicitní hodnotě některého sloupce, v některém vnitřním integritním omezení nebo v některém triggeru. O této kategorii chyb hovoříme jako o chybách v objektech na pozadí. Vývojář může zapnout záznam těchto chyb do logu a tak se dozvědět, že v aplikaci jsou stále nekonzistence.
602SQL nebrání tomu, aby databázové objekty byly současně používány a modifikovány. Ve většině situací jakmile je některý objekt změněn začne se používat jeho nová verze.
Existují situace, kdy může dojít k nesouladu verzí objektů. Předpokládejme, že procedura A volá proceduru B. Nechť se pro jednoho klienta právě provádí na serveru procedura A. Jiný klient v té době změní proceduru B, například přidá do její hlavičky další parametr. Jakmile procedura A dospěje do místa, kde volá proceduru B, zjistí, že tuto akci nemůže provést, protože nesouhlasí počet parametrů. Nastane chyba OBJECT_VERSION_NOT_AVAILABLE neboli "Objekt byl změněn".
Kdyby procedura A byla zavolána až po změně v B, pak by chyba byla odhalena již během překladu A a vůbec by nedošlo k jejímu spuštění. Chyba OBJECT_VERSION_NOT_AVAILABLE nastane tehdy, když je používán objekt odkazující na měněný objekt. Jiným příkladem situace vedoucí k této chybě je změna ve funkci F provedená v době, kdy se pracuje s tabulkou, která volá F uvnitř svého integritního omezení.
Pokud by tato chyba přetrvávala, pak vždy pomůže zastavit a znovu spustit server.
Při práci s klientským vývojovým prostředím je sice teoreticky možné otevřít explicitní transakci, ale nelze spoléhat na to, že tato transakce "přežije" interaktivní práci při vývoji a používání aplikace. Je nejvýš pravděpodobné, že nejbližší akce vyvolá implicitní rollback nebo commit a transakce se ukončí. Implicitní rollback může snadno odvolat část práce, která je tím ztracena.
| Aplikace | Export a šíření aplikace | |