Definícia položiek a formulárov - vnútorná reprezentácia

V této kapitole naleznete popis, jakým způsobem jsou definovatelné položky a formuláře reprezentovány v tabulkách v databázi ABRA Gen. Bežný užívateľ nebude tieto informácie na svoju prácu potrebovať, môže teda túto kapitolu preskočiť.

Obsah kapitoly:

Obyčajné alebo "neextra" položky - vnútorná reprezentácia

Na riešenie obyčajných alebo "neextra" udf položiek sú v databáze k dispozícii nasledujúce tabuľky:

UserFieldDefs

Obsahuje hlavičkové údaje definícií definovateľných položiek. Zoznam existujúcich definícií je pre užívateľa k dispozícii v agende Definovateľné položky - v záložke Zoznam. Tabuľka hlavičiek definícií obsahuje hlavne:

  • identifikáciu Business objektu (CSLID), ku ktorému sa daná definícia sady definovateľných položiek viaže
  • vlastnú identifikáciu definície

UserFieldDefs2

Obsahuje vlastné definície definovateľných položiek. Každý záznam o. i. obsahuje:

  • jednoznačný odkaz na hlavičku definície (jeden zo záznamov z tabuľky UserFieldDefs)
  • kód definovateľnej položky (FieldCode) jednoznačný v rámci zoznamu definovateľných položiek k danej triede objektov - pomocou tohto kódu sa potom na danú položku odkazuje a to:
    • jednak z definovateľných formulárov
    • jednak z tabuľky konkrétnych dát
  • množstvo ďalších položiek týkajúcich sa konkrétnej definície

UserData

Obsahuje všeobecné dáta užívateľsky nadefinovaných položiek jednotlivých BO. Každý záznam obsahuje o. i.:

  • identifikáciu Business objektu (CSLID), ku ktorému sa daná položka a jej hodnota viaže
  • identifikáciu danej položky odkazom pomocou kódu položky (FieldCode)
  • vlastnú hodnotu, príp. pri číselníkových položkách odkaz do inej tabuľky na zodpovedajúci záznam číselníka

Dáta užívateľsky definovateľných položiek nemusia nutne všetky ležať v tejto tabuľke, môžu byť umiestnené aj v ďalších tabuľkách podobnej štruktúry. Aká tabuľka na uloženie takýchto dát bude použitá, je dané programom (napr. pre skupinu Mzdy a personalistika sa nepoužíva priamo tabuľka UserData, ale iná špeciálne za týmto účelom zavedená, v tomto prípade napr. UserWgData.)

HistoryData

Variant predchádzajúcej tabuľky, ale slúži na ukladanie historických hodnôt užívateľsky nadefinovaných položiek, ktoré podporujú históriu.

Podobne ako v predchádzajúcej tabuľke platí, že tieto dáta užívateľsky definovateľných položiek nemusia všetky nutne ležať v tejto tabuľke, môžu byť umiestnené aj v ďalších tabuľkách podobnej štruktúry. Aká tabuľka na uloženie takýchto dát bude použitá, je dané programom (napr. pre skupinu Mzdy a personalistika sa nepoužíva priamo tabuľka HistoryData, ale iná špeciálne za týmto účelom zavedená, v tomto prípade napr. HistoryWgData.)

Späť na obsah / začiatok kapitoly

Extra položky - vnútorná reprezentácia

Vnútorná realizácia

Extra udf položky jsou (na rozdíl od "neextra" položek) v databázi uloženy přímo v tabulkách příslušejících Business objektu, pro který jsou nadefinovány.

Protože v systému ABRA Gen může existovat současně více spojení (connections) na databázi (dále viz nástroj DbAdmin.exe) a v každém spojení je možné mít odlišné struktury tabulek, je třeba i odděleně evidovat informace o extra položkách a samozřejmě i informace o základních SQL akcích. Preto sú informácie o extra položkách k danej triede (o definícii ich štruktúry) uložené nielen v tabuľke UserFieldDefs ako ostatné "neextra" Udf položky, ale aj v repository a to v mieste podriadenom príslušnému spojeniu na databázu. Táto časť repository je súčasťou zálohy. Viď Čo obsahuje záloha *.ABF.

Jak bylo již zmíněno v kap. Definice položek a formulářů - obecné, po změně v definicích extra Udf položek je podle jejich definice zajištěna úprava struktury odpovídajících tabulek v databázi a úprava základních SQL akcí (select, insert, update) pro práci s nimi a to i za běhu systému ABRA Gen (je-li to možné).

Platí:

  • Pri uložení alebo zmazaní definície extra udf položky sa automaticky vykoná korekcia zodpovedajúcich informácií v repository.

    O korekcii informácií v repository sa nestará Business objekt definície, ale vizuálno. Z toho plynie, že tam, kde nie je toto "vizuálno" k dispozícii, napr. v AbraOLE, je to potrebné špeciálne ošetriť.

  • Pri uložení alebo zmazaní definície extra udf položky sa automaticky príslušne upravia štruktúry tabuliek (pokiaľ je to možné).

    Okrem príkazu, ktorý vykoná rozšírenie štruktúry tabuľky, sa vykoná i príkaz UPDATE, ktorý do nového stĺpca všetkým záznamom tabuľky nastaví príslušnú východiskovú hodnotu.

    Ak chcete pridať extra položku nad tabuľkou s mnohými záznamami (napr. firemný adresár), ktorá má navyše nadefinované nejaké triggery vykonávajúce nejakú nezanedbateľnú činnosť (napr. pri akejkoľvek zmene záznamu (INSERT, UPDATE, DELETE) vytvoria nový záznam do nejakej pomocnej tabuľky), neodporúča sa toto za bežného denného chodu firmy, pretože táto akcia by jednak mohla veľmi vyťažiť server a jednak, ak ide o často používanú tabuľku, by mohla zlyhať, pretože s tabuľkou môže akurát pracovať niekto iný.
    Odporúčanie: extra položky pridávať mimo bežný prevádzku, a to hlavne v prípadoch, ako je spomenuté vyššie. Príp. si overiť spúšťané triggery a dočasne ich vypnúť (toto odporúčame robiť iba veľmi znalým užívateľom alebo servisným konzultantom dodávateľa).

    Táto automatická korekcia nemusí byť úspešná (pokiaľ je daná tabuľka práve používaná). Preto je v agende užívateľsky definovateľných položiek k dispozícii funkcia Korekcia na ručné vyvolanie kontroly resp. korekcie príslušných tabuliek.

    Vykoná ALTER TABLE tablename ADD FIELDS … podľa aktuálnych definícií extra položiek.

    Aby sa užívateľ nemusel o aktualizácii týchto informácií v repository resp. v tabuľkách databázy starať, zaktualizujú sa automaticky pri štarte systému, ak je to potrebné. Ku kontrole potreby synchronizácie extra položiek medzi databázou a repository slúži automaticky generovaný GUID v špeciálnej pomocnej tabuľke (ExtraFieldsStamp). Po vykonaní zmeny v definíciách extra položiek sa do tejto tabuľky zapíše nový GUID. Při dalším startu ABRA Gen se po výběru spojení provádí kontrola shody tohoto GUID oproti GUID evidovaném v repositoři. Pokiaľ sa nezhodujú, indikuje to, že boli vykonané zmeny v definíciách extra položiek, ale nedošlo z nejakého dôvodu k adekvátnym korekciám informácií uložených v repository resp. k úprave štruktúr databázových tabuliek a je potrebné ich vykonať. Tzn. vykoná sa aktualizácia záznamov v repository tak, aby zodpovedali definíciám extra položiek, a korekcia tabuliek databázy tak, aby zodpovedali definíciám extra položiek, resp. teda aj aktuálnym záznamom v repository.

    V predchádzajúcich verziách (do v. 10.01. vrát. slúžil k podobným účelom špeciálny príznak v nastavení spojenia na databázu Repository v súlade s databázou (ConnectionIsOK)).

    Uživatel, který změnu struktury provedl (pokud se podařila), může pracovat s novou strukturou daného BO, a nemusí nutně systém ABRA Gen ukončit a spustit znovu. Ostatní uživatelé, aby mohli korektně pracovat s novou strukturou daného BO, musí systém ukončit a spustit znovu.

    POZOR ale na upozornenie v ďalších bodoch!!!

  • Pri porovnávaní, ktoré položky je potrebné odstrániť, ktoré naopak doplniť, sa rozhoduje len podľa mena položky – nekontroluje sa ani dátový typ, ani veľkosť.
  • Je možné přenést databázi a připojit ji do jiné instalace systému ABRA Gen (samozřejmě stejné verze), aniž by se uživatel musel starat o aktualizaci těchto informací v repositoři - zaktualizují se automaticky při startu systému, viz výše.
  • Keď vznikne nové spojenie na databázu, prebehne pri kontrole spojenia (pri spustení systému ABRA) aktualizácia informácií o extra položkách v repository, čím sa zabezpečí, že aj SQL akcie, ktoré pracujú s tabuľkami príslušných Business objektov, zodpovedajú štruktúre databázy.

    Firebird CS "kešuje" metadata (informace o tabulkách) ke každému konkrétnímu spojení, přičemž ve v. 1.5 platí, že se u FB CS tyto keše navzájem nesynchronizují. Současně aby se co nejvíce urychlila reakce systému ABRA Gen na nově otevíraná spojení, je v systému aplikován mechanismus odkládání spojení (tj. po zavření se nezahazují, ale "odkládají" a následně se použijí (kolik jich může být odloženo, tj. zda vůbec nějaké může být odloženo, a jak dlouho, závisí na nastavení parametrů v NEXUS.CFG)).

    To však tiež môže znamenať, že pokiaľ by v sieťovej prevádzke jeden klient pridal extra položku, tak by nemuselo stačiť druhému zavrieť a otvoriť systém, pretože by po opätovnom zapnutí mohol dostať skôr odložené spojenie, ktoré kvôli kešovaniu má stále "starú" štruktúru tabuliek (bez novo pridanej extra položky), čo by viedlo k chybám. Preto sa po vytvorení extrapoložky resp. po vykonaní príkazu ALTER, ktorý mení štruktúru tabuľky, vyvolá špeciálna metóda, ktorá spôsobí "zahodenie nakešovaných spojení na dbserver" na aplikačnom serveri. Tým sa dosiahne vyčistenie "odložených" spojení. Súčasne je zabezpečené, aby sa spojenia existujúce v dobe vyvolania tejto metódy už neodložili do keša (cache). Tedy pokud ABRA Gen běží síťově a s ní dva klienti, pak pokud jeden z nich přidá extra položku a druhý zavře a znovu se spustí, dostane nové spojení s databází, protože to původní se nezařadí do keše. Tím je tedy zajištěno, že po přidání extra položky v síťovém běhu, by neměly nastat problémy u jiných klientů, drobnou nevýhodou je, že se trochu zpomalí reakce systému na nově otevírané spojení po přidání extra položky.

    Firebird 1.5 však od verze 9.01 již není podporován.

  • Počet extra položiek, ktoré je možné nadefinovať, je obmedzený:
    • maximálnym počtom položiek v tabuľke
    • počtom zmien, ktoré je možné uskutočniť so štruktúrou jednej tabuľky do doby zálohy a obnovy databázy (cca 255).

Z informací uvedených výše plyne, že uživatel, který změnu struktury provedl (pokud se podařila), může teoreticky pracovat s novou strukturou daného BO, aniž by nutně musel systém ABRA Gen ukončit a spustit znovu (nicméně se to doporučuje). Ostatní užívatelia, aby mohli korektne pracovať s novou štruktúrou daného BO a mali zaistené, že všetko bude fungovať korektne, musia nutne systém ukončiť a spustiť znova.

Nicméně kromě "kešování u FB" uvedeného výše, dochází i k různým jiným "kešováním" souvisejícím s aplikačním serverem, které by za určitých výjimečných okolností teoreticky mohly vést k nějakému problému (např. že se v nějaké spuštěné ABRA Gen nebudou ukládat do nově přidaných extra položek hodnoty, jelikož o nich daná ABRA zatím "neví" apod). Preto pre pridanie extra položiek odporúčame nasledujúci postup, ktorý zahŕňa i reštart aplikačného servera, pokiaľ chcete vylúčiť možné problémy.

Odporúčaný postup pre pridanie extra položiek (a iné zmeny v ich definíciách):

  • zmeny v definíciách extra položiek vykonávať zásadne mimo bežnú prevádzku !!!!! (tzn. vtedy, pokiaľ žiadny iný klient so systémom nepracuje)
  • po změně v definicích extra položek provést restart aplikačního serveru (minimálně si tím zajistíte, že se restartují všichni případně přihlášení klienti)
  • následne až potom začať novo pridané extra položky používať, tzn. zadávať do nich dáta
  • podobne pre iné zmeny v extra položkách

Od v. 10.02 sa databáza obnoví zo zálohy presne tak, ako bola v okamihu zálohovania. Tzn. pokiaľ obsahovala extra položky, obnoví sa i s nimi a po obnove dát nie je teda potrebné podľa definícií zazálohovaných v repository nejak ešte upravovať štruktúry tabuliek, ako tomu bolo predtým pred verziou 10.02. Predtým sa najprv štandardne vytvorili základné tabuľky tak, ako boli dodávané výrobcom, a potom sa do nich pomocou špeciálnych skriptov typu "ALTER TABLE tablename ADD FIELDS …" pridali položky podľa zazálohovaných definícií extra položiek

Späť na obsah / začiatok kapitoly

Obmedzenia pre definíciu extra položiek v rámci niektorých Business objektov

V niektorých prípadoch zdieľa viacero Business objektov (BO) jednu tabuľku. Príklady objektov, ktoré používajú spoločnú tabuľku:

V takom prípade je možné extra položky definovať len pre jednu triedu daných BO a to nasledovne:

  • buď u třídy jednoho z nich (viz případ rolí a skupin rolí, kdy je možno definovat extra položky pro BO "Role" (SecurityRole), ale už ne pro BO "Skupiny rolí" (SecirityGroup))
  • alebo v rámci triedy nadradeného BO, pokiaľ ide o prípad, že pre danú skupinu BO existuje nejaký nadradený BO (viď prípad skladových dokladov, keď je možné definovať extra položky pre BO "Skladový doklad" (CustomStoreDocument), ale nie už pre BO dodacieho listu a iných sklad. dokladov).

Pre ostatné triedy BO, ktoré ukladajú svoje dáta do rovnakej tabuľky, táto možnosť nie je, ale pretože sa zmena štruktúry vykonáva nad spoločnou tabuľkou, aj tieto objekty poznajú nové extra položky a môžu tak s nimi pracovať. Tieto extra položky však nie sú priamo viditeľné v definícii definovateľných položiek týchto BO, ale iba vo formulároch (pri výbere položky, viď voľba Pridať položku v definícii formulára).

K triede BO "Rola" si nadefinujeme extra položku X_pokus. Ak sa budeme pozerať na zoznam definovateľných položiek nadefinovaných k triede BO "Skupina rolí", položka X_pokus tam uvedená nebude, no keď budeme pre triedu BO "Skupina rolí" definovať definovateľný formulár, bude sa nám položka X_pokus ponúkať na výber.

V editácii Udf položiek takéhoto Business objektu sa zobrazuje informácia o tom, v ktorom Business objektu je možné extra položky definovať.

Späť na obsah / začiatok kapitoly

Pravidlá použitia prefixov a kódov Udf položiek

  • Obyčajné "neextra" Udf položky
    • Systémové majú prefix S_ a kód v rozmedzí od 1000000 do 1999999 vrátane.
    • Nesystémové obyčajné ("neextra") Udf položky majú prefix U_ a kód väčší alebo rovný 2000000.
  • Extra Udf položky
    • Systémové majú prefix Y_ a kód v rozmedzí od 800000 do 899999 vrátane.
    • Nesystémové majú prefix X_ a kód v rozmedzí od 900000 do 999999 vrátane.

    Kódy užívateľsky definovateľných položiek sa prideľujú až pri uložení. Novo vytvorená užívateľsky definovateľná položka má kód rovný nule. Pri ukladaní celej definície pri položkách, ktoré majú kód rovnajúci sa nule, prebehne pridelenie správneho kódu. Stará sa o to priamo Business objekt, nie je to preto potrebné napr. v AbraOLE nijako špeciálne ošetrovať. Ten, kto bude definície udf položek spravovať pomocou AbraOLE, môže teda kódy položiek buď nastaviť sám s ohľadom na pravidlá uvedené vyššie alebo ich nechať nastavené na nula, a BO definície sa o to sám postará.

Späť na obsah