Přechod mezi systémy ABRA Gen (migrace)

V praxi dochází často k potřebě přechodu mezi různými instalacemi ABRA Gen. Typicky je to v případě, kdy chce uživatel přejít z jednoho produktu ABRA Gen na jiný (např. z produktu ABRA Gen s daňovou evidencí na ABRA Gen s podvojným účetnictvím, příp. z produktu ABRA Gen pro Firebird na ABRA Gen pro Oracle či ABRA Gen pro MSSQL). Důvodem může být to, že uživatel např. požaduje nějakou funkcionalitu, která není dodávána k nižší produktové řadě a chce přejít na vyšší, vedl daňovou evidenci, ale nyní musí začít vést podvojné účetnictví, chce změnit databázovou platformu a přejít na výkonnější databázový server apod. Přechod je teoreticky možný i obráceně, tj. z "vyššího" produktu na "nižší". Stejný přechod lze realizovat i mezi dvěma instalacemi téhož systému, pokud to z nějakého důvodu potřebujete.

Postup je následující:

• ve zdrojové instalaci se provede export dat ze zdrojové databáze následovně:

  Pomocí nástroje DBExport se do souboru formátu databázový export (*.DBE) vyexportují data z vybraného spojení. Postup provedení a co je obsahem vyexportovaných dat, viz popis nástroje DBExport.

• v cílové instalaci se provede vytvoření nové databáze s importem těchto vyexportovaných dat následovně:

  V nástroji DBAdmin:

  • se zvolí volba Přidat nové spojení pro vytvoření nové databáze v cílové instalaci ABRA Gen (tím se zajistí vytvoření nové databáze dle souboru CreateDB.DBO, tedy vytvoří se databázové objekty systému ABRA Gen se správnou syntaxí příslušné platformy).
  • v následujícím kroku Vlastnosti spojení je třeba zatrhnout volbu "Zobrazit pokročilé vlastnosti" a poté zpřístupněnou volbu "Editovat zákaznické úpravy".
  • v kroku Zákaznické úpravy se zatrhne volba "Nahrát data ze souboru" a připojí se soubor *.DBE vyexportovaný z nástroje DBExport, z něhož se vytvořená databáze naplní daty vyexportovanými z původní databáze
  • v kroku Zákaznické úpravy je k dispozici i možnost zadat "Adresář s DBO soubory". Je-li použita, pak se nová databáze vytvoří podle *.DBO souborů v tomto adresáři. Toto však nebudete pro běžný přechod mezi systémy potřebovat (je určeno pro řešení specifických servisních situací). Více viz popis v nástroji DBAdmin.

  Pokud jste ve zdrojové databázi přidávali nějaké vlastní databázové entity (sloupce, vlastní tabulky, procedury, triggery, ...) a chcete je mít i na importní straně, je třeba zajistit jejich přidání do nově vytvořené databáze a to následovně:

  • v kroku Zákaznické úpravy přidat *.DBO soubory s vlastními zákaznickými úpravami. Jedná se o vlastní *.DBO soubory, které se mají spustit (a operace z nich se mají provést) v různých fázích průběhu vytváření nové databáze.

  Vlastní import přidání takových entit nijak neřeší (a ani nemůže, informace o nich nejsou obsaženy ve vyexportovaných datech). Pokud vyexportovaná data obsahují data z uživatelských sloupců, tabulek či sekvencí, ale nezajistíte přidání těchto entit na importní straně, nebude možné tato data naimportovat, import se zastaví, viz dále.

  Jak bylo uvedeno v popisu nástroje DBAdmin, zatím neexistuje nástroj, jak takové vlastní *.DBO soubory získat ze zdrojové instalace automaticky a musíte si je vytvořit ručně pomocí nástroje DBOperations (DBO soubory jsou totiž binární soubory a uživatel je nemůže vytvořit jinak než prostřednictvím nástroje DBOperations).

  Pokud jste zákaznické úpravy zdrojové databáze prováděli ve verzi vyšší než 10.02, je vám postup (pomocí *.DBO souborů) již známý. Pokud jste zákaznické úpravy prováděli ve verzi nižší, pracovali jste se systémem *.NXD souborů, který se pro tento účel používal dříve. Pokud v takovém případě nebudete vědět, jak na to a jak nyní vytvořit potřebné zákaznické *.DBO soubory, objednejte si jejich vytvoření v servisním oddělení dodavatele.

Po spuštění cílové instalace s tímto novým spojením, se vytvoří nová databáze, přičemž se případně provedou zákaznické úpravy, byly-li zadány vlastní *.DBO soubory, a naimportují se do ní data z *.DBE souboru.

V souboru NEXUS.CFG můžete změnit počet vláken procesoru, které budou použity při importu dat z *.DBE souborů. Správné nastavení tohoto parametru (vzhledem k modelu vašeho procesoru) zrychlí nahrávání do databáze. Tento a další konfigurační parametry naleznete v Konfigurační soubor Nexus.cfg - oddíly a parametry.

V průběhu importu může nastat situace, kdy exportní soubor obsahuje tabulku, sloupec tabulky nebo sekvenci, která v cílovém spojení neexistuje. V takovém případě import zobrazí dialogové okno s volbou Zopakovat nebo Přeskočit. Je tedy možné takové hodnoty buď vůbec do nově tvořené databáze neimportovat (přeskočit) anebo import přerušit, chybějící databázový objekt nejdříve doplnit (ručně např. pomocí nástroje DBOperations) a poté pokračovat v importu.

K takové situaci může dojít typicky v případě, kdy jste si na exportní straně přidávali např. vlastní tabulky, jejichž hodnoty jsou obsaženy v exportovaných datech, ale nezajistili jste jejich přidání na importní straně, jak bylo řečeno výše.

Převod uživatelských definic (číselníků, DynSQL)

• V původním systému ABRA Gen spustit nástroj DynSQLEditor.exe. Importovat jen uživatelské definice a tyto definice uložit do TXT.
• V původním systému ABRA Gen spustit nástroj DefRollEditor.exe. Importovat jen uživatelské definice číselníků a tyto uložit do TXT.
• V novém systému ABRA Gen v daných nástrojích, viz body výše otevřít uložený soubor a zvolit možnost Export uživatelských definic.

Následně je třeba zkontrolovat, že uživatelská DynSQL neobsahují na platformě závislé SQL fragmenty a případně tyto fragmenty opravit na novou platformu.

Převod uživatelských definic (číselníků, DynSQL) pomocí Instalačních sad

Po vytvoření nové databáze z DBE souboru, nebude tato nová instalace obsahovat uživatelské definice uložené v repozitoři původního systému ABRA Gen (soubor Storage.STF).

Před prováděním jakýkoli změn si v nové i původní instalaci za zálohujte soubor Storage.STF.

1. V původní instalaci spusťte v systému ABRA Gen agendu Instalační sady. Vytvořte novou instalační sadu a přidejte do ní všechny Definovatelné číselníky a Dynamické SQL, které chcete do nové instalace převést.
2. Dokončete průvodce a funkcí Exportovat sadu uložte instalační sadu do souboru.
3. V nové instalaci spusťte v systému ABRA Gen agendu Instalační sady. Vyberte funkci Importovat sadu -> Expertní import a nainstalujte všechny objekty z v předešlém kroku vytvořené instalační sady.

Převod uživatelských definic (číselníků, DynSQL) pomocí nástrojů DynSQLEditor.exe a DefRollEditor.exe

Pozor, níže uvedený původní způsob, tedy s importem a exportem jen uživatelských DynSQL, nepřenáší nastavení, kdy uživatelský objekt je použit na systémovém objektu.

Typicky kdy je uživatelské DynSQL použito v systémovém objektu Místa v programu.

• V původním systému ABRA Gen spustit nástroj DynSQLEditor.exe. Importovat jen uživatelské definice a tyto definice uložit do TXT.
• V původním systému ABRA Gen spustit nástroj DefRollEditor.exe. Importovat jen uživatelské definice číselníků a tyto uložit do TXT.
• V novém systému ABRA Gen v daných nástrojích, viz body výše otevřít uložený soubor a zvolit možnost Export uživatelských definic.

Následně je třeba zkontrolovat, že uživatelská DynSQL a další objekty uložené v databázi neobsahují na platformě závislé SQL fragmenty a případně tyto fragmenty opravit na novou platformu.

Best-practice přechodu mezi systémy ABRA Gen

Postup:

1. Provést přechod do nové testovacím systému ABRA Gen určené pro odladění všech funkcí.
2. Najít a upravit všechna DynSQL, která obsahují platformově závislé SQL fragmenty.
3. Najít a upravit všechny uživatelské objekty v databázi, které obsahují platformově závislé SQL fragmenty.
4. Uživatelské testování a kontrola pomocí SQL monitoringu.
5. Vytvoření finální instalační sady obsahující všechny upravené uživatelské objekty.
6. Přechod do nové ostré instalace systému ABRA Gen.

Podmínkou postupu je že v průběhu úprav a vytváření finální instalační sady nedojde ke změnám žádného z upravovaných objektů nebo vytváření nových v původním systému ABRA Gen.

Aby nemohlo dojít k potížím, kdy některý z nástrojů systému ABRA Gen nebude mít načtenu aktuální repozitoř, doporučujeme veškeré úpravy provádět v lokálním režimu. Toto se netýká se samotného vytváření databází.

Předpokladem úspěšného vytváření instalačních sad je dostupnost všech objektů, na které se jednotlivé objekty odkazují.

ad 1) Provést přechod do nového testovacího systému systému ABRA Gen určeného pro odladění všech funkcí

Vytvoření nového DBE exportu ve zdrojové ostré instalaci. Vytvoření nové instalace ABRA Gen s novou databázi z DBE a pomocí instalačních sad do ní převést uživatelské definice z DynSQL, viz. výše.

ad 2) Najít a upravit všechna DynSQL, která obsahují platformově závislé SQL fragmenty

Pro vyhledání těchto fragmentů lze použít nástroj UserCustomizationChecker.exe dodávaný v instalaci ABRA Gen. Případně si v nástroji DynSQLEditor vyexportovat všechna uživatelská DynSQL do souboru a provést vyhledání v něm. Pro úpravu použijte nástroj DynSQLEditor.

ad 3) Najít a upravit všechny uživatelské objekty v databázi, které obsahují platformově závislé SQL fragmenty

Tyto fragmenty SQL se mohou vyskytovat mimo jiné v těchto objektech:

• Balíčky skriptů
• Definice omezení a Filtry – podmínka Výraz
• Definovatelné Exporty
• Definovatelné formuláře
• Fulltextové hledání
• Naplánované úlohy
• Panely definovatelných údajů
• Tiskové sestavy
• Uživatelské sloupce
• Variantní vstupní formuláře
• Kategorizační údaje
• SCM

Pro vyhledání a kontrolu mohou sloužit:

• Nástroj UserCustomizationChecker.exe: U vybraných druhů objektů provádí automatickou kontrolu přímo vykonáním SQL. Případně umožňuje dohledat předem vytipované chybné fragmenty SQL.
• Vybrané agendy (např. Přehled omezení, Variantní formuláře apod.): Pomocí omezení v agendách lze dohledat předem vytipované chybné fragmenty SQL. Např. v agendě Definice omezení lze omezit za výraz „a.dsqlvalues like '%A.%'“ a pomocí něj dohledat všechny záznamy, které v podmínkách obsahují hodnotu „A.“
• Ruční kontrola spuštěním v ABRA: Některé neglobální uživatelské objekty jsou v ABRA Gen vidět pouze pro uživatele, kteří je vytvořili. Např. Omezení a Filtry nebo Panely definovatelných údajů. Pro kontrolu takovýchto Omezení a Filtrů jiným uživatelem je možné v agendě Přehled omezení změnit nastavení na Globální a po odladění opět vrátit zpět. Obdobně je toto možné provést u Panelů definovatelných údajů. Vzhledem k tomu že pro tyto objekty neexistuje agenda je možné je na globální přepnout pouze zásahem v databázi (tabulka CENTRALSTORAGE, dotaz PATH LIKE '%SiteDetailDefinitions%' – pokud je v user_id null je globální).
• Kontrola přímo v databázi
• Vytvoření instalační sady s danou skupinou objektů, její vyhrání do souboru a textová kontrola v tomto souboru. Od verze 24.1 jsou instalační sady výchoze vytvářeny jako zazipované soubory obsahující xml s jednotlivými uživatelskými objekty. Po rozzipování je možné tyto xml prohledat a dohledat v nich předem vytipované chybné fragmenty SQL.

ad 4) Uživatelské testování a kontrola pomocí SQL monitoringu

Po odladění všech uživatelský objektů doporučujeme vyzkoušení plné funkcionality uživateli ABRA Gen. Během tohoto testování je vhodné sledovat provoz ABRA Gen pomocí SQL monitoring (dostupný od verze 25.3.x) a odhalit případné další chybná nebo neodladěná déle trvající SQL. Zároveň doporučujeme pomocí nástroje UserCustomizationChecker.exe provést všechny zde nabízené kontroly.

ad 5) Vytvoření finálních instalační sad(y) obsahující všechny upravené uživatelské objekty

Po řádném testování je možné vytvořit novou instalační sadu, která bude použita pro finální vytvoření nové ostré instalace. Z důvodu přehlednosti je možné vytvoření více instalačních sad, v tomto případě je doporučujeme seskupovat tak jak spolu jednotlivé druhy objektů souvisí, např. Dynamické SQL a definovatelné číselníky do jedné sady. Neglobální Definice Omezení, Panely definovatelných údajů a Variantní vstupní formuláře je možné přenášet pomocí instalačních sad až od verze 25.3.x.

ad 6) Přechod do nové ostré instalace ABRA Gen

Zastavení provozu v původní nyní zdrojové instalaci ABRA Gen. Vytvoření nového DBE exportu s aktuálními daty. Vytvoření nové databáze z nového DBE exportu v nové ostré instalaci ABRA Gen. Instalace finální instalační sady obsahující všechny odladěné uživatelské objekty. Spuštění ostrého provozu v nové ostré instalaci ABRA Gen.

Často kladené dotazy

Důležité rozdíly v produktech ABRA Gen

ABRA Gen pro MSSQL používá před ID prefix ~.

ABRA Gen pro Oracle oproti ABRA Gen pro Firebird a MSSQL používá jiné třídění.

Během vytváření instalační sady se zobrazuje chyba cannot create instance

Agenda instalační sady se pokouší načíst odkazovaný objekt který již neexistuje, např. Tisková sestava se odkazuje na neexistující uživatelské DynSQL, nebo uživatelské DynSQL které se dále odkazuje na neexistující uživatelské DynSQL.

Pozor v tomto případě se nedostaly do instalační sady všechny objekty a je potřeba problém nejdříve vyřešit a poté se pokusit vytvořit instalační sadu znovu.

Nejsnazším způsobem o dohledání více informací o problémovém objektu je vyhrání všech DynSQL v nástroji DynSQLEditor do souboru. A následné prohledání tohoto souboru. CLSID z chybové hlášky je před vyhledáváním nutné převést na ShortCLSID, k tomu slouží nástroj GUID conversion dostupný zde ABRA Tools.

V určitých případech, např při načítání Tiskových sestav do instalační sady se může zobrazit místo chyby s konkrétním CLSID pouze text Interface not supported.

V tomto případě (případně i jiných) lze chybný objekt dohledat dle posledních záznamů v seznamu objektů která instalační sada zobrazila. Instalační sady načítají záznamy tak jak je vrací databázový server, tedy prázdný řádek je ten chybný a lze jej v databázi určit dle předchozích záznamů. K prohlížení záznamů v databázi je nutné použít nástroj který záznamy sám výchoze neřadí např. DBeaver.

Co s neexistujícími objekty, případně jinými objekty, které se na ně odkazují?

Nejdříve je nutné ověřit, zda k problému nedošlo omylem při práci s DynSQL. Ověřte, že objekt neexistuje v původní ostré zdrojové instalaci, případně ověřte, zda se nevyskytuje v některých ze záloh systému ABRAGen. Pokud zde ani v jiných zdrojích nelze původ objektů odhalit, je možné rozhodnout o jeho zrušení, ale toto rozhodnutí bude vždy individuální. Nicméně všechny objekty navázané na chybějící v systému chybovali a nebylo možné je ani v původní ostré instalaci používat. Každopádně před smazáním nebo jakoukoliv prací doporučujeme objekt a všechny objekty na něj navázané za zálohovat (Možnost uložení definic do souboru nabízí nástroje DynSQLEditor.exe, DefRoll.exe a další, případě je možnost za zálohovat celou repozitoř).

Chyby Panelů definovatelných údajů v nástroji UserCustomizationChecker.exe

Zápis ve výpisu nástroje UserCustomizationChecker.exe (zobrazeno jako CSV):

Neznámá agenda (XXXRE20IPZDL342W01C0CX3FCC)

Nepodařilo se dohledat zdrojovou agendu panelu. Nejspíš se jedná o již neexistující definovatelný číselník.. Zkontrolujte, zda se daný GUID nevyskytuje v původní zdrojové instalaci, případně v některé ze záloh a pokračujte dle kapitoly výše.

Neznámá agenda (00000000000000000000000000) - PPC2EX0BUJD13ACP03KIU0CLP4)

Nástroj nedohledal správný zdroj dat panelu v agendě s GUID PPC2EX0BUJD13ACP03KIU0CLP4 (Faktury přijaté – lze dohledat v GenDoc.chm). Typicky se jedná o řádky dokladů.

Všechny panely pro speciální agendy, jak jsou Účetní žádosti, Mzdové listy apod. nástroj UserCustomizationChecker.exe detekuje jako chybné. Tyto panely je nutné zkontrolovat ručně.

Více o konkrétním panelu lze uživatelsky zjistit po vyexportováním instalační sady obsahující panel do souboru (více výše). V databázi lze panely dohledat pomocí dotazu do tabulky CentralStorage s podmínkou PATH LIKE %SiteDetailDefinitions%PPC2EX0BUJD13ACP03KIU0CLP4%'. Zde by mělo být poté porovnáním možné dohledat název panelu a další informace.

Technologie zástupných znaků v SQL dotazech

Proto, aby bylo možné SQL dotazy připravit již na verzi 22.0 a přechod na Unicode verzi se co nejvíce urychlil, byla do ABRA Gen implementována technologie zástupných znaků, které dle verze ABRA Gen doplní nové nezbytné části SQL dotazů.

Od verze 22.0.0 ServicePack 26 respektive 22.0.1 ServicePack 24 jsou tyto zástupné znaky nahrazeny prázdným znakem.

Od verze 22.1.0 ServicePack 4 respektive 22.1.1. ServicePack 3 a výše jsou nahrazeny takto:

ORACLE:

@{N} a @{NATIONAL} je nahrazeno znakem N

@{COLLATEUNICODE} je nahrazeno COLLATE XCZECH_CI resp. COLLATE XSLOVAK_CI resp. COLLATE XGERMAN_CI

@{COLLATEORA_USING_NLS_COMP} je nahrazeno COLLATE USING_NLS_COMP

@{unicodeNvarcharCast(String what, int size, boolean withCollate)} provede CAST, a případně dle třetího parametru COLLATE(výchozí hodnota je true).

MSSQL:

@{COLLATEUNICODE} vloží COLLATE Czech_CI_AS resp. COLLATE Slovak_CI_AS resp. Latin1_General_CI_AS

@{unicodeNvarcharCast(String what, int size, boolean withCollate)} vloží pouze zadané ID

Ostatní zástupné znaky (viz seznam pro Oracle), pokud budou použity, jsou nahrazeny prázdným znakem.

K přechodu mezi ABRA Gen s daňovou evidencí a ABRA Gen

Dodatečné úpravy v datech po přechodu mezi těmito systémy plynou především z těchto jejich odlišností, které se týkají účtování:

• V produktu ABRA Gen s daňovou evidencí je pouze jediný Typ organizace a předvyplňují se dle něj pouze záznamy do definic uzávěrky mezd podle vzorů. V ostatních produktech je k dispozici více typů organizací a po prvním výběru typu organizace se automaticky doplní záznamy do účtového rozvrhu, účetních předkontací a definic uzávěrky mezd podle vzorů pro vybraný typ organizace. Bez nich nelze účtovat. Dodatečné pozdější změny je nutno řešit ručně porovnáním s dodávanými vzory.
• Množina typů dokladů, dodávaná výrobcem v rámci inicializačních dat pro produkt ABRA Gen s daňovou evidencí a pro ostatní produkty, není stejná. V ABRA Gen s daňovou evidencí je navíc např. typ Ostatní zápisy a naopak některé typy nejsou k dispozici, jelikož nemají pro ABRA Gen s daňovou evidencí význam (např. typ Interní doklady).
• V produktu ABRA Gen s daňovou evidencí se neúčtuje jako v podvojném účetnictví a všechny typy dokladů mají nastavenu položku Účtovat na Ne (což nelze uživatelsky v daném číselníku měnit), tudíž i všechny řady dokladů budou mít nastaveno Neúčtovat.

Tato nastavení jsou součástí inicializačních dat pro jednotlivé produkty ABRA Gen. Jak bylo ale objasněno u výkladu inicializačních dat, u migrace se soubor inicializačních dat z principu migrace nevyužívá - initdata se (stejně jako ostatní data) nahrají ze souboru *.DBE přesně tak, jak byla v původní databázi (což je záměr).

Je tedy třeba jiným způsobem zajistit doplnění převedených dat v cílovém produktu - možným řešením je např. vyhrát obsah všech potřebných tabulek z nově vytvořené "běžné" databáze naplněné aktuálně dodávanými inicializačními daty cílového produktu pomocí nástroje Scripter.exe a převést je poté do dat převedených z původního produktu ABRA Gen (tedy např. do dat převedených z produktu ABRA Gen s daňovou evidencí). Kontaktujte servisní oddělení výrobce. Dále si musí uživatel založit nové řady dokladů se správně nastaveným účtováním pro cílový produkt a je-li cílovým produktem produkt s podvojným účetnictvím, musí si převzít vzory těch účtů a předkontací, které potřebuje, postupným porovnáním s dodávanými vzory (pokud si je nevyhrál také z příslušných tabulek (Accounts, AccPresetDefs, AccPresetDefs2), a pak by stačilo je pouze zkontrolovat, případně upřesnit dle vlastní potřeby.