Aktualizování v číselnících, cacheování (kešování) číselníků

Jak bylo objasněno v kapitole popisující technologii zpracování dat, systém IS FLORES jakožto databázová klient/server aplikace má data spravována samostatným databázovým serverem. Při práci s daty je tedy nutno komunikovat s databázovým serverem prostřednictvím tzv. SQL dotazů, příslušná data se pak ukládají z databáze do paměti klientského počítače a naopak.

Jelikož číselníky jsou uživatelem používány pro zadávání, vybírání hodnot atd. a to opakovaně a často, přičemž některé z nich mohou být i velmi rozsáhlé - např. Adresář firem, Seznam artiklů apod., nebylo by žádoucí, aby při každém vyvolání číselníku se prováděl odpovídající dotaz do databáze a na klientskou aplikaci, tj. k uživateli, se pokaždé předávaly celé číselníky znovu. Takový postup by neúnosně zpomalil práci se systémem. Proto jsou téměř všechny číselníky nějakým způsobem drženy v paměti, tzv. "cacheovány". (Kešovány.)

Číselník se do paměti načte:

• buď celý - ve většině případů
• nebo jen jeho část - jen u číselníků podporujících Skupiny záznamů, pokud je nějaká skupina zvolena

  U některých vybraných číselníků, jako je např. číselník Artiklů, Skladů a Firem, jsou z důvodu urychlení cacheovány nejen data, ale i vizuální vzhled daného číselníku.

Tzn., že při první potřebě daného číselníku, se provede příslušný SQL dotaz na databázový server a záznamy odpovídajícího číselníku nebo jeho části (odpovídající skupině záznamů) se načtou do paměti počítače, na kterém běží klientská aplikace. Tento číselník (celý nebo jeho načtená část) se pak uchovává v paměti (je cacheován) a odtud se používá při dalším vyvolání, neprovádí se tedy nový dotaz do databáze.

Klientská aplikace pak pracuje s daty, které má načtené v paměti. Tato technologie má však drobnou nevýhodu:

• bez ručního zásahu uživatele (vyvolání aktualizace) není možné promítnout změny, ke kterým mohlo mezitím v databázi dojít
• existence kolizí

Jak bylo uvedeno výše, číselník se při svém prvním použití načte z databáze do paměti počítače (celý nebo dle zvolené skupiny záznamů), je omezen pouze přístupovými právy. Při jeho dalším vyvolání se nabízí dle stavu v paměti. Mezitím ale může dojít ke změně dat v databázi:

• Přidáme, opravíme nebo smažeme některý ze zobrazených záznamů v číselníku. Tato změna se projeví ihned jednak v aktuálně otevřeném číselníku, ale i při jeho dalším vyvolání v rámci téhož okna. Zobrazený číselník tedy odpovídá stavu v paměti i aktuálnímu stavu databáze. Nepromítne se jedině v agendě, která již byla v okamžiku změny otevřena. Objasníme na příkladu:

  Příklad 1: Mějme v paměti načten číselník zakázek, v něm nechť je zakázka Z1-zakázka1 a Z2-zakázka2. Otevřeme agendu zakázek a poté ještě jednou agendu zakázek (ve stejném okně aplikace). V jedné z nich provedeme např. opravu Z1 na ZX-zakázkaX. Pokud vyvoláme agendu zakázek potřetí (např. z řádků faktury), zobrazí se aktuální stav, tj. se zakázkou ZX.

  Pokud přepneme do druhé otevřené agendy zakázek, změnu tam nevidíme, tj. je tam stále zakázka Z1 a to až do aktualizace. (U číselníků stačí provést aktualizaci jen v jedné z otevřených agend číselníku v rámci jednoho okna aplikace, aktualizace se promítne do všech).

  Nově přidaný nebo opravený záznam je v číselníku zobrazen tučně a to až do okamžiku provedení aktualizace, aby bylo zřejmé, že některé ze zobrazených záznamů byly opraveny nebo nově přidány.

• Přidání, smazání nebo opravu některého z námi zobrazených dokladů provede jiný uživatel v síti, resp. ji provedeme my, ale z agendy otevřené v samostatném okně aplikace. Potom zobrazený číselník sice odpovídá stavu v paměti, ale neodpovídá aktuálnímu stavu v databázi. Objasníme na příkladu:

  Příklad 2: Mějme v paměti načten číselník zakázek, v něm nechť je zakázka Z1-zakázka1 a Z2-zakázka2. Mezitím např. jiný uživatel v síti opraví zakázku Z1 na ZY. Nám se ale tato změna neprojeví (zobrazujeme stav předtím načtený do paměti). Obdobně každé další otevření zakázek bude zobrazovat stále stav v paměti, tj. stále se nabízí zakázka Z1 a můžeme ji použít.

K řešení těchto situací slouží funkce Aktualizovat (F11), tudíž nejdříve provedeme aktualizaci seznamu a poté budeme mít k dispozici aktuální stav přesně tak, jak je v databázi SQL serveru. Po stisku funkce Aktualizovat systém provede znovu SQL dotaz dle aktuálního omezení na databázový server a načtení do paměti z databáze.

Pozor, pokud došlo např. ke smazání nějakého námi zobrazovaného záznamu z jiné stanice a nebyla provedena aktualizace, pak takový záznam se v seznamu stále zobrazuje, nicméně je invalidní (neplatný). Pak platí:

• Pokud kurzor stojí na takovém neplatném objektu, není dovoleno pro tento záznam přepínat záložky. Pokud stojíme na jiné záložce, než Seznam, dojde k přepnutí na záložku Seznam (jedná se o záložky na úrovni záložky Seznam).
• Pokud kurzor stojí na takovém neplatném objektu a je vyvolána funkce Aktualizovat, pak není provedena synchronizace pozice kurzoru se stavem před aktualizací (jelikož to nelze) a kurzor bude umístěn na začátku seznamu.

Při používání číselníků v číselníkových položkách platí následující:

• V číselníkových položkách se nepamatují konkrétní hodnoty z číselníku, ale pouze odkazy na tyto hodnoty přes tzv. interní identifikátory ID (vnitřní kód programu uživateli nepřístupný)
• Pokud zobrazujeme či opravujeme doklad, na kterém je nějaká číselníková položka, zobrazí se její kód (název či jiná hodnota), který je pro daný identifikátor uveden v číselníku aktuálně načteném v paměti. Objasníme na příkladech:

  Příklad 3: Mějme načten číselník zakázek, v něm nechť je zakázka Z1. Mezitím však např. jiný uživatel v síti provedl změnu kódu zakázky Z1 na "ZX". Zobrazujeme fakturu vystavenou na zakázku Z1, v řádcích faktury je zobrazen kód Z1. Pokud provedeme aktualizaci číselníku zakázek a zobrazíme znovu fakturu, bude v řádcích již zobrazen kód ZX.

  Příklad 4: Mějme načten číselník zakázek, v něm nechť je zakázka Z1. Mezitím však např. jiný uživatel v síti provedl změnu kódu zakázky Z1 na "ZX". Opravujeme fakturu vystavenou na zakázku Z1, v položce zakázka se stále nabízí kód Z1 (kód ZX ani nelze zadat, dokud neprovedeme aktualizaci číselníku) a s kódem Z1 se i uloží případná oprava faktury. (To ale není na závadu, jelikož na faktuře se nepamatuje přímo kód zakázky, ale její interní identifikátor, uživateli nepřístupný, a ten se nezměnil.) Pokud provedeme aktualizaci číselníku zakázek a opravujeme znovu fakturu, bude v řádcích již zobrazen kód ZX.

  Příklad 5: Mějme načten číselník zakázek, v něm nechť je zakázka Z1. Mezitím však jiný uživatel v síti smazal zakázku Z1, Z1 zatím není použita, a proto ji lze zcela smazat. Nemáme aktualizován číselník a vystavujeme fakturu na Z1. Zakázka se nabízí a je ji možno vybrat (číselník nebyl aktualizován), při uložení faktury zjistí, že zakázka Z1 s příslušným interním identifikátorem již v databázi neexistuje, tuto skutečnost ohlásí a uložení takového dokladu nepovolí.)

  Příklad 6: Mějme načten číselník zakázek, v něm nechť je zakázka Z1. Mezitím však jiný uživatel v síti smazal zakázku Z1, Z1 je však již použita na dokladu, a proto ji nelze zcela smazat, je pouze skryta. Opravujeme fakturu vystavenou na zakázku Z1. Aktualizujeme si číselník. Na faktuře je uvedena zakázka Z1. Pokud na položce zakázka vyvoláme číselník, zakázka Z1 se v něm k výběru již nenabízí, pokud položku zakázka neopravujeme, zůstane na faktuře po uložení zakázka Z1 (což je v pořádku, na faktuře je zakázka, která na ni byla zadána, i když nyní již neexistuje).

  Příklad 7: Mějme načten číselník zakázek, v něm nechť je zakázka Z1. Mezitím však jiný uživatel v síti smazal zakázku Z1, Z1 je však již použita na dokladu, a proto ji nelze zcela smazat, je pouze skryta. Vystavujeme novou fakturu na zakázku Z1. Ale neaktualizujeme si číselník, tudíž lze vybrat zakázku Z1 a uložit. (Identifikátor zakázky Z1 v databázi existuje, jelikož není smazána, ale pouze skryta, tudíž takovou fakturu lze uložit).
  Obdobně, pokud nemáme aktualizovaný číselník a jiný uživatel např. zakázku uzavře.

Situacím popsaným v posledním příkladu předejdete, pokud budete průběžně data aktualizovat !