Definice položek a formulářů - vnitřní reprezentace

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. Běžný uživatel nebude tyto informace ke své práci potřebovat, proto může tuto kapitolu přeskočit.

Obsah kapitoly:

Obyčejné neboli "neextra" položky - vnitřní reprezentace

Pro řešení obyčejných neboli "neextra" udf položek jsou v databázi k dispozici následující tabulky:

UserFieldDefs

Obsahuje hlavičkové údaje definic definovatelných položek. Seznam existujících definic je uživateli k dispozici v agendě Definovatelné položky - v záložce Seznam. Tabulka hlaviček definic obsahuje hlavně:

  • identifikaci Business objektu (CSLID), k němuž se daná definice sady definovatelných položek váže
  • vlastní identifikaci definice

UserFieldDefs2

Obsahuje vlastní definice definovatelných položek. Každý záznam mj. obsahuje:

  • jednoznačný odkaz na hlavičku definice (jeden ze záznamů z tabulky UserFieldDefs)
  • kód definovatelné položky (FieldCode) jednoznačný v rámci seznamu definovatelných položek k dané třídě objektů - přes tento kód je pak na danou položku odkazováno a to:
    • jednak z definovatelných formulářů
    • jednak z tabulky konkrétních dat
  • řadu dalších položek týkajících se konkrétní definice

UserData

Obsahuje obecná data uživatelsky nadefinovaných položek jednotlivých BO. Každý záznam obsahuje mj.:

  • identifikaci Business objektu (CSLID), k němuž se daná položka a její hodnota váže
  • identifikaci dané položky odkazem přes kód položky (FieldCode)
  • vlastní hodnotu, příp. u číselníkových položek odkaz do jiné tabulky na odpovídající záznam číselníku

Data uživatelsky definovatelných položek nemusí všechna nutně ležet v této tabulce, mohou být umístěna i v dalších tabulkách obdobné struktury. Jaká tabulka pro uložení takových dat bude použita, je dáno programem (např. pro skupinu Mzdy a personalistika se nepoužívá přímo tabulka UserData, ale jiná speciálně pro tento účel zavedená, v tomto případě např. UserWgData.)

HistoryData

Obdoba předchozí tabulky, ale slouží pro ukládání historických hodnot uživatelsky nadefinovaných položek, které podporují historii.

Obdobně jako u předchozí tabulky platí, že tato data uživatelsky definovatelných položek nemusí všechna nutně ležet v této tabulce, mohou být umístěna i v dalších tabulkách obdobné struktury. Jaká tabulka pro uložení takových dat bude použita, je dáno programem (např. pro skupinu Mzdy a personalistika se nepoužívá přímo tabulka HistoryData, ale jiná speciálně pro tento účel zavedená, v tomto případě např. HistoryWgData.)

Zpět na obsah / začátek kapitoly

Extra položky - vnitřní reprezentace

Vnitřní realizace

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. Proto jsou informace o extra položkách k dané třídě (o definici jejich struktury) uloženy nejen v tabulce UserFieldDefs jako ostatní "neextra" Udf položky, ale také v repositoři a to v místě podřízeném příslušnému spojení na databázi. Tato část repositoře je součástí zálohy. Viz Co 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í:

  • Při uložení nebo smazání definice extra udf položky se automaticky provede korekce odpovídajících informací v repozitoři.

    O korekci informací v repositoři se nestará Business objekt definice, ale vizuálno. Z toho plyne, že tam, kde není toto"vizuálno" k dispozici, např. v AbraOLE, je to potřeba speciálně ošetřit.

  • Při uložení nebo smazání definice extra udf položky se automaticky příslušně upraví struktury tabulek (pokud to lze).

    Kromě příkazu, který provede rozšíření struktury tabulky, se provede i příkaz UPDATE, který do nového sloupce u všech záznamů tabulky nastaví příslušnou výchozí hodnotu.

    Pokud chcete přidat extra položku nad tabulkou s mnoha záznamy (např. firemní adresář), která má navíc nadefinované nějaké triggery provádějící nějakou nezanedbatelnou činnost (např. při jakékoliv změně záznamu (INSERT, UPDATE, DELETE) vytvoří nový záznam do nějaké pomocné tabulky), nedoporučuje se toto za běžného denního běhu firmy, jelikož taková akce by jednak mohla velmi vytížit server a jednak pokud se jedná o často používanou tabulku, by mohla stejně selhat, jelikož s tabulkou může zrovna pracovat někdo jiný.
    Doporučení: extra položky přidávat mimo běžný provoz a to zejména v případech, jako je zmíněno výše. Příp. si ověřit spouštěné triggery a dočasně je vypnout (toto doporučeno provádět pouze velmi znalým uživatelům či servisních konzultantů dodavatele).

    Tato automatická korekce nemusí být úspěšná (pokud je daná tabulka právě používána). Proto je v agendě uživatelsky definovatelných položek k dispozici funkce Korekce pro ruční vyvolání kontroly resp. korekce příslušných tabulek.

    Provede ALTER TABLE tablename ADD FIELDS … podle aktuálních definic extra položek.

    Aby se uživatel nemusel o aktualizaci těchto informací v repositoři resp. v tabulkách databáze starat, zaktualizují se automaticky při startu systému, je-li to potřeba. Ke kontrole potřeby synchronizace extra položek mezi databází a repozitoří slouží automaticky generovaný GUID ve speciální pomocné tabulce (ExtraFieldsStamp). Po provedení změny v definicích extra položek se do této tabulky 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. Pokud se neshodují, indikuje to, že byly provedeny změny v definicích extra položek, ale nedošlo z nějakého důvodu k adekvátním korekcím informací uložených v repositoři resp. k úpravě struktur databázových tabulek a je potřeba je provést. Tj. provede se aktualizace záznamů v repositoři tak, aby odpovídaly definicím extra položek, a korekce tabulek databáze tak, aby odpovídaly definicím extra položek, resp. tudíž i aktuálním záznamům v repositoři.

    V předchozích verzích (do v. 10.01. vč. sloužil k podobným účelům speciální příznak v nastavení spojení na databázi Repositoř v souladu s databází (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 upozornění v dalších bodech!!!

  • Při porovnávání, které položky je třeba odstranit, které naopak doplnit, se rozhoduje pouze podle jména položky – nekontroluje se ani datový typ, ani velikost.
  • 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.
  • Pokud vznikne nové spojení na databázi, provede se při kontrole spojení (při spuštění systému ABRA) aktualizace informací o extra položkách v repozitoři, čímž se zajistí, že i SQL akce, které pracují s tabulkami příslušných Business objektů, odpovídají struktuře databáze.

    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 ovšem může znamenat, že pokud by v síťovém běhu jeden klient přidal extra položku, pak by nemuselo stačit druhému zavřít a otevřít systém, jelikož by po opětovném zapnutí mohl dostat dříve odložené spojení, které díky kešování má stále "starou" strukturu tabulek (bez nově přidané extra položky), což by vedlo k chybám. Proto se po vytvoření extrapoložky resp. tedy po vykonání příkazu ALTER, který mění strukturu tabulky, volá speciální metoda, která způsobí "zahození nakešovaných spojení na dbserver" na aplikačním serveru. Tím se dosáhne vyčištění "odložených" spojení. Současně je zajištěno, aby spojení existující v době volání této metody se již neodložila do keše. 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žek, které lze nadefinovat, je omezen:
    • maximálním počtem položek v tabulce
    • počtem změn, které je možné provést se strukturou jedné tabulky do doby zálohy a obnovy databáze (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živatelé, aby mohli korektně pracovat s novou strukturou daného BO a měli zajištěno, že vše bude fungovat korektně, musí nutně systém ukončit a spustit znovu.

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). Proto pro přidání extra položek doporučujeme následující postup, který zahrnuje i restart aplikačního serveru, pokud chcete vyloučit možné potíže.

Doporučený postup pro přidání extra položek (a jiné změny v jejich definicích):

  • změny v definicích extra položek provádět zásadně mimo běžný provoz!!!!! (tj. tehdy, pokud žádný jiný klient se systémem 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)
  • teprve poté začít nově přidané extra položky používat, tj. zadávat do nich data
  • obdobně pro jiné změny v extra položkách

Od v. 10.02 se databáze obnoví ze zálohy přesně tak, jak byla v okamžiku zálohování. Tj. pokud obsahovala extra položky, obnoví se i s nimi a po obnově dat není tedy třeba podle definic zazálohovaných v repositoři nějak ještě upravovat struktury tabulek, jako tomu bylo dříve před verzí 10.02. Dříve se nejdříve standardně vytvořily základní tabulky tak, jak byly dodávány výrobcem, a poté se do nich pomocí speciálních skriptů typu "ALTER TABLE tablename ADD FIELDS …" přidaly položky podle zazálohovaných definic extra položek

Zpět na obsah / začátek kapitoly

Omezení pro definici extra položek u některých Business objektů

V některých případech sdílí více Business objektů (BO) jednu tabulku. Příklady objektů, které používají společnou tabulku:

V takovém případě lze definovat extra položky pouze u jedné třídy daných BO a to následovně:

  • 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))
  • nebo u třídy nadřazeného BO, pokud se jedná o případ, že pro danou skupinu BO existuje nějaký nadřazený BO (viz případ skladových dokladů, kdy je možno definovat extra položky pro BO "Skladový doklad" (CustomStoreDocument), ale už ne pro BO dodacího listu a jiných sklad. dokladů).

U ostatních tříd BO, které ukládají svá data do téže tabulky, tato možnost k dispozici není, ale protože se změna struktury provádí nad společnou tabulkou, i tyto objekty znají nové extra položky a mohou s nimi pracovat. Tyto extra položky ale nejsou přímo viditelné v definici definovatelných položek těchto BO, ale pouze ve formulářích (při výběru položky, viz volba Přidat položku v definici formuláře).

Ke třídě BO "Role" si nadefinujeme extra položku X_pokus. Pokud se budeme dívat na seznam definovatelných položek nadefinovaných ke třídě BO "Skupina rolí", tak tam položka X_pokus uvedena nebude, ale pokud budeme pro třídu BO "Skupina rolí" definovat definovatelný formulář, bude se nám položka X_pokus nabízet k výběru.

V editaci Udf položek takového Business objektu se zobrazuje informace o tom, ve kterém Business objektu je možné extra položky definovat.

Zpět na obsah / začátek kapitoly

Pravidla pro použití prefixů a kódů Udf položek

  • Obyčejné "neextra" Udf položky
    • Systémové mají prefix S_ a kód v rozmezí od 1000000 do 1999999 včetně.
    • Nesystémové obyčejné ("neextra") Udf položky mají prefix U_ a kód větší nebo roven 2000000.
  • Extra Udf položky
    • Systémové mají prefix Y_ a kód v rozmezí od 800000 do 899999 včetně.
    • Nesystémové mají prefix X_ a kód v rozmezí od 900000 do 999999 včetně.

    Kódy uživatelsky definovatelných položek se přidělují až při uložení. Nově vytvořená uživatelsky definovatelná položka má kód roven nule. Při ukládání celé definice se u položek, které mají kód roven nule, provede přidělení správného kódu. O toto se stará přímo Business objekt, není to tedy potřeba např. v AbraOLE nijak speciálně ošetřovat. Ten, kdo bude definice udf položek spravovat pomocí AbraOLE, může tedy kódy položek buď nastavit sám s ohledem na pravidla uvedená výše nebo je nechat nastavené na nula, a BO definice se o to sám postará.

Zpět na obsah