Pokud Rozkopírování nerozkopíruje záznamy, zkuste nastavení:
V případě, že neexistuje vazba na podřízený číselník
nastavit na hodnotu:
Rozkopírovat bez vazby
Tato drobná změna poměrně často pomůže.
2. Vlastnosti rozkopírování
Rozkopírování z principu nemůže a nikdy nebude fungovat „bez chyb“. Chyby jsou a budou korektně ošetřené a zalogované, ale na konkrétních datech bude docházet k tomu, že některé záznamy nebudou rozkopírovány.
Například – chceme rozkopírovat číselník organizací
Ve zdrojové a cílové databázi mohou existovat ty samé organizace, ale ve zdrojové databázi mají jiné ID a jiné Číslo organizace než v databázi cílové.
Klíčový sloupec je tedy ICO.
Pokud v cílové databázi neexistuje dané IČO, tak se záznam vloží.
Pokud v cílové databázi existuje dané IČO, tak se záznam aktualizuje podle zdrojového záznamu
Zdá se to jasné, srozumitelné a jednoduché.
Ale sloupec IČO je nepovinný a není unikátní, takže jak ve zdrojové, tak i v cílové databázi může existovat více záznamů se stejným IČO.
Rozkopírování takovýchto řádků pak logicky musí skončit s chybou a stejně tak skončí s chybou rozkopírování číselníků, které mají sloupec IDOrg či CisOrg.
3. Logování chyb
Bylo by krásné, kdyby rozkopírování zahlásilo chybu „V tabulce Organizací máte duplicitní IČO 123456“, proto nelze organizace rozkopírovat.
Tohoto stavu se ale nikdy nedosáhne. Příkaz, který převádí data se dynamicky a velice komplikovaně sestavuje na základě konfigurace.
Pro každý číselník, který rozkopírováváme se standardně rozkopírovávají i podřízené číselníky a výsledný příkaz pro každou podřízenou tabulku může být na několik obrazovek.
Příklad rozkopírování Čísel organizací při kopírování kmenových karet:
Opravdu není možné zjistit, v které části příkazu dochází k chybě.
4. Světlo na konci tunelu
A teď ta lepší zpráva
Do logovací tabulky byl přidán sloupec, ve kterém se loguje příkaz, který způsobil chybu. To může značně zjednodušit analýzu při hledání problému.
Ani v tomto případě to není procházka růžovým sadem, ale odpadá celkem složité trasování přes Profiler.
Změna bude/byla v roce 2020 v prosincové verzi Helios Orange.
4. Úprava číselníku
Existuje možnost, jak problémový sloupec nerozkopírovávat.
Po rozkopírování číselníku lze zkontrolovat tabulku TabRozkopErrDetail
SELECT * FROM TabRozkopErrDetail
ORDER BY 1 DESC
Zde je nejen zalogovaná chyba, ale i příkaz, který chybu vyvolal.
Příkaz může vypadat poměrně složitě, zde je ukázka:
V principu bere příkaz řádek po řádku podle záznamů označených k rozkopírování. Pokud se rozkopírovává celá tabulka, tak stejně bere řádek po řádku, ale ID jsou všechna ID v tabulce.
Pokud se podaří zjistit, které sloupce způsobují chybu (třeba: „Subquery returned more than 1 value")
tak existují možnosti (kromě změny dat), jak chybu eliminovat:
- Nastavit sloupec tak, aby se vůbec nekopíroval v konkrétní tabulce
INSERT INTO TabRozkopXX (TabName, Atribut, VynechatTabulku)
VALUES('TabBankSpojeni','IDOrg','0')
... Při rozkopírování tabulky TabBankSpojení se nebude rozkopírovávat sloupec „IDOrg“ - Nastavit tabulku tak, aby se nerozkopírovávala
INSERT INTO TabRozkopXX (TabName, Atribut, VynechatTabulku)
VALUES('TabCisOrg', NULL, '0')
... Při rozkopírování se nebude rozkopírovávat tabulka TabCisOrg i když je podřízeným číselníkem - Nastavit sloupec tak, aby se nikdy v žádné tabulce nerozkopírovával
INSERT INTO TabRozkopXX (TabName, Atribut, VynechatTabulku)
VALUES('VSECHNY', 'CisloOrg', '0')
Děkuji všem, kteří dočetli až sem
Josef Kořenský