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

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

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

Tabuľky obsahujú všeobecné dáta užívateľsky nadefinovaných položiek jednotlivých BO. Každý záznam obsahuje:

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

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 modul 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.)

Extra udf položky sú (na rozdiel od "neextra" položiek) v databáze uložené priamo v tabuľkách prislúchajúcich k Business objektu, pre ktorý sú nadefinované.

Pretože v systéme ABRA Gen môže existovať súčasne viacero spojení (connections) na databázu (ďalej viď nástroj DbAdmin.exe) a v každom spojení je možné mať odlišné štruktúry tabuliek, je potrebné oddelene evidovať aj informácie o extra položkách a samozrejme i informácie o základných SQL akciá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.

Ako bolo spomenuté v kap. Definícia položiek a formulárov - všeobecné, po zmene v definíciách extra Udf položiek je podľa ich definície zaistená úprava štruktúry zodpovedajúcich tabuliek v databáze a úprava základných SQL akcií (select, insert, update) na prácu s nimi, a to i počas chodu systému ABRA Gen (ak je 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. Pri ďalšom štarte ABRA Gen sa po výbere spojenia vykonáva kontrola zhody tohto GUID oproti GUID evidovanému v repository. 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žívateľ, ktorý zmenu štruktúry vykonal (pokiaľ sa vydarila), môže pracovať s novou štruktúrou daného BO, a nemusí systém ABRA Gen ukončiť a spustiť znova. Ostatní užívatelia, aby mohli korektne pracovať s novou štruktúrou daného BO, musia systém ukončiť a spustiť 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é preniesť databázu a pripojiť ju do inej inštalácie systému ABRA Gen (samozrejme rovnakej verzie), bez toho aby sa užívateľ musel starať o aktualizáciu týchto informácií v repository - zaktualizujú sa automaticky pri štarte systému, viď vyššie.

• 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" metadáta (informácie o tabuľkách) ku každému konkrétnemu spojeniu, pričom vo v. 1.5 platí, že sa v rámci FB CS tieto keše navzájom nesynchronizujú. Súčasne aby sa čo najviac urýchlila reakcia systému ABRA Gen na novo otvárané spojenia, je v systéme aplikovaný mechanizmus odkladania spojení (tzn. po zavretí sa nezahadzujú, ale "odkladajú" a následne sa použijú (koľko ich môže byť odložených, tzn. či vôbec nejaké môže byť odložené, a ako dlho, závisí od nastavenia parametrov 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). Takže pokiaľ ABRA Gen beží sieťovo a s ňou dvaja klienti, tak pokiaľ jeden z nich pridá extra položku a druhý zatvorí a znovu sa spustí, dostane nové spojenie s databázou, pretože to pôvodné sa nezaradí do keša (cache). Tým je teda zaistené, že po pridaní extra položky v sieťovej prevádzke, by nemali nastať problémy u iných klientov, drobnou nevýhodou je, že sa trochu spomalí reakcia systému na novo otvárané spojenie po pridaní extra položky.
  
  Firebird 1.5však od verzie 9.01 už nie je podporovaný.

• 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 informácií uvedených vyššie plynie, že užívateľ, ktorý zmenu štruktúry vykonal (pokiaľ sa vydarila), môže teoreticky pracovať s novou štruktúrou daného BO bez toho, aby nutne musel systém ABRA Gen ukončiť a spustiť znova (avšak je to odporúčané). 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.

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 zmene v definíciách extra položiek vykonať reštart aplikačného servera (minimálne si tým zaistíte, že sa reštartujú všetci prípadne prihlásení 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

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

• Roly a Skupina rolí
• Skladové doklady nepolohovacie i polohovacie a riadky takýchto skladových dokladov
• Užívateľsky definovateľné číselníky

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

• buď v rámci triedy jedného z nich (viď prípad rolí a skupín rolí, keď je možné definovať extra položky pre BO "Rola" (SecurityRole), ale nie už pre BO "Skupiny rolí" (SecurityGroup))
• 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).