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

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

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

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

• identifikaci Business objektu (CLSID), 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 (StringFieldValue)

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 modul Mzdy a personalistika se nepoužívá přímo tabulka HistoryData, ale jiná speciálně pro tento účel zavedená, v tomto případě např. HistoryWgData.)

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 repozitoři a to v místě podřízeném příslušnému spojení na databázi. Tato část repozitoř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 repozitoř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 repozitoř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 repozitoř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 repozitoři resp. k úpravě struktur databázových tabulek a je potřeba je provést. Tj. provede se aktualizace záznamů v repozitoř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 repozitoř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 Repozitoř 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 repozitoř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.

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

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

• Role a Skupina rolí
• Skladové doklady nepolohovací i polohovací a řádky takových skladových dokladů
• Uživatelsky definovatelné číselníky

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í" (SecurityGroup))
• 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).