Vývojové prostředí

Příručka ve formátu PDF

1. Úvod

• Tato příručka popisuje problematiku práce s vývojovým prostředím. Jednotlivé kapitoly obsahují:

• Jak vytvořit nové vývojové prostředí
• Jak vývojové prostředí přenést do provozního
• Jak a proč řešit kolize v původní a nové struktuře databáze
• Jak přenést provozní data do vývojového prostředí

2. Vytvoření nového vývojového prostředí

• Tento proces lze charakterizovat následujícími kroky:

1. Vytvoření (instalace) nového NET Genia
2. Nastavení vývojového NET Genia
3. Záloha provozní databáze
4. Obnova provozní databáze ve vývojovém prostředí

2.1. Vytvoření vývojového NET Genia

• Spočívá v instalaci nového NET Genia. Instalaci charakterizuje příručka Instalace NG

2.2. Nastavení vývojového NET Genia

• Licence – pro nahrání licence do vývojového NET Genia lze použít kopii provozního licenčního klíče. Zkopírujte tedy soubor „license.txt“ z adresáře „Config“ provozního NET Genia do adresáře „Config“ vývojového.
• Externí funkce – pokud NET Genium využívá naprogramované externí funkce, lze je přenést zkopírováním souboru „ngef.dll“, případně také „ngef.pdb“ do vývojového prostředí (adresář „bin“). Stejně tak je nutné překopírovat další programové knihovny, které mohou být využívané v knihovně „ngef.dll“, typicky například „ERP.dll“.
• Tiskové šablony – pro přenesení tiskových šablon zkopírujte obsah adresáře „Templates“ provozního NET Genia do adresáře „Templates“ vývojového.
• Souborové přílohy – pro přenesení souborových příloh zkopírujte obsah adresáře „Files“ provozního NET Genia do adresáře „Files“ vývojového.

2.3. Záloha provozní databáze

• Pro zálohování provozní databáze využijte program „SqlBackup.exe“. Nachází se v adresáři „Backup“. Podporuje zálohování databází MSSQL i Firebird.
• Použití:

SqlBackup.exe [zdroj] [cíl]

• Parametr zdroj specifikuje název databáze (MSSQL) nebo plnou cestu k databázi na disku (Firebird).
• Parametr cíl specifikuje název souboru, do kterého bude záloha uložena.

Při spuštění bez parametrů nabídne program několik voleb v závislosti na prováděné činnosti.

• Zálohu (backup) databáze provede volba B. Program po spuštění vyhledá všechny dostupné databáze dle výchozích instancí MSSQL serveru ((local) a (local)\SQLEXPRESS) nebo na základě záznamů v registrech a nabídne uživateli, kterou databázi má zálohovat. V případě databáze Firebird se automaticky prohledávají umístění „E:\Firebird“, „D:\Firebird„ a „C:\Firebird“.
• Při spuštění programu „SqlBackup.exe“ lze použít také parametr –S, kterým lze specifikovat konkrétní instanci MSSQL serveru v případě, že se některá jeho instance nenalezne automaticky (tj. nemá záznam v registrech systému pod klíčem „HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft SQL Server\Instance Names\SQL“ nebo má jiný než výchozí název instance).
• Příklad užití:

SqlBackup.exe –S(local)\SQLEXPRESS

• Metodika práce s databázemi MSSQL a Firebird je odlišná. V případě MSSQL serveru je databáze identifikována dle názvu databáze a instance SQL serveru, zatímco Firebird databáze je identifikována přímou fyzickou cestou k databázi. Zálohovaná MSSQL databáze má příponu „. bak“. Firebird záloha má příponu „.fbk“. Vytvořená záloha se nachází ve stejném adresáři, ve kterém se nachází spuštěná aplikace „SqlBackup.exe“ (bez parametrů).

• Volby BTHIS nebo BT zálohuje databázi, která je uvedena v souboru „ConnectionString.txt“ ve složce „Config“.

2.4. Obnova provozní databáze

• Příslušnou provozní databázi zkopírujte z provozního NET Genia do adresáře „Backup“ vývojového. Obnovu je nutné provádět prostřednictvím programu „SqlBackup.exe“ ve vývojovém NET Geniu.
• Obnovu (restore) databáze provede volba R. „SqlBackup.exe“ vyhledá všechny zálohy ve svém umístění odkud je spuštěn a po jejich nalezení nabídne uživateli, kterou databázi má obnovit.

• Po vybrání zálohy, z které má být provedena obnova, budete vyzváni k zadání názvu nové obnovené databáze.

• Z bezpečnostních důvodů budete dále vyzváni k potvrzení vloženého názvu nové obnovené databáze.

• Na závěr procesu obnovy budete dotázáni, zde se má obnovená databáze uložit do výchozího (defaultního) adresáře MSSQL / Firebird.

3. Přenesení vývojového prostředí do provozního

• Tento přenos je možné charakterizovat dvěma základními kroky:

1. Export struktury databáze (merge) ve vývojovém prostředí
2. Import struktury databáze (merge) v provozním prostředí
3. Pro exportování a importování je určen program „SqlBackup.exe“. Podporuje export databází MSSQL i Firebird, a taktéž i následný import. Export a import je možné provádět i napříč různými databázemi, například z databáze MSSQL do databáze Firebird a naopak.

3.1. Export (vývojové prostředí)

• Před exportem databáze je nutné sjednotit verzi NET Genia ve vývojovém i provozním prostředí – číslo verze a typ verze (plná vs. testerská). Nejjistější způsob je aktualizovat na nejnovější verzi NET Genia, a zároveň počkat na nastartování NET Genia resp. zobrazení přihlašovací stránky. Teprve po nastartování NET Genia máme jistotu, že byla provedena i aktualizace vývojové databáze na nejnovější verzi.
• Volba E. Program automaticky exportuje databázi, která je uvedena jako používaná databáze v souboru „ConnectionString.txt“ v adresáři „Config“, a uloží ji do aktuálního umístění programu. Dále vyberte volbu č. 3.

• Volba č. 3 – Database structure (merge) – exportuje strukturu databáze (vše kromě dat v uživatelských databázových tabulkách). Export je proveden do ZIP souboru, který má název „yyyy-mm-dd-název_databáze.zip”.
• Takto vyexportovanou strukturu vývojové databáze poté zkopírujte do provozního prostředí do adresáře „Backup“ k programu „SqlBackup.exe“.

3.2. Import (provozní prostředí)

• Před importem databáze je nutné sjednotit verzi NET Genia ve vývojovém i provozním prostředí – číslo verze a typ verze (plná vs. testerská). Nejjistější způsob je aktualizovat na nejnovější verzi NET Genia, a zároveň počkat na nastartování NET Genia resp. zobrazení přihlašovací stránky. Teprve po nastartování NET Genia máme jistotu, že byla provedena i aktualizace provozní databáze na nejnovější verzi.
• Volba I. Program „SqlBackup.exe“ v umístění, kde je uložen, automaticky vyhledá ZIP soubor s exportovanou strukturou vývojové databáze. Tuto databázi tedy vyberte k importu.
• V dalším kroku jsou důležité především volby 3 a 4.

• Volba č. 3 – Database structure (merge) – importuje strukturu databáze.
• Volba č. 4 – Database structure (merge test) – spustí simulaci importu, a generuje report „SqlBackup.htm“, ve kterém jsou uvedeny všechny rozdíly v datových strukturách uživatelských databázových tabulek mezi vývojovým a provozním prostředím. Pokud tento report obsahuje pouze slovo „OK“, nejsou mezi strukturami databází žádné rozdíly. Dále vytváří soubor „SqlBackup.sql“, který obsahuje seznam všech SQL příkazů, které zajišťují konverzi stávající struktury databáze na nový stav. Merge test je důležité zvolit vždy před samotným provedením importu!

3.2.1. Merge test

• Merge test znamená simulaci importu nové struktury databáze, který se provádí kvůli identifikaci možných kolizí mezi databázovými tabulkami a jejich sloupci. Kolize v původní a nové struktuře databáze mohou nastat v různých situacích. Je důležité je řešit kvůli případnému narušení integrity provozní databáze a ztrátě dat.
• Na obrázku níže je zobrazen příklad obsahu souboru „SqlBackup.htm“. Tento soubor je programem „Sqlbackup.exe“ vygenerován při každém provedení merge testu.
  

• Sloupec OLD označuje provozní (současnou aktuální) databázi, NEW označuje vývojovou (importovanou) databázi. Položky, u kterých došlo ke změnám, jsou zvýrazněny červenou barvou.
• V souboru „SqlBackup.htm“ je důležité projít každou tabulku s rozdíly a posoudit, zde je zvýrazněná změna v pořádku. Mohou nastat tři základní situace, které mají fatální důsledky, a jejichž přehlédnutím nebo zanedbáním dochází ke ztrátě dat!

1. Smazání sloupečku, který se nachází v provozním prostředí, ale již se nenachází ve vývojovém prostředí, tedy v importované databázi – NET Genium smaže sloupeček v provozní databázi, a dochází ke ztrátě dat uložených v tomto sloupečku. Následující příklad znázorňuje situaci, kdy je v provozní databázi sloupeček „ng_telefon2“, a provedením merge bude tento sloupeček odstraněn.
   
2. Přejmenování sloupečku – NET Genium nejdříve smaže sloupeček s původním názvem, a následně vytvoří nový sloupeček s novým názvem. Aby nedošlo ke ztrátě dat smazáním sloupečku s původním názvem, je nutné před zmergováním provozní databáze přejmenovat v provozní databázi původní sloupeček na nový název. Tuto situaci může znázorňovat i obrázek výše, kdy mohlo dojít ve vývojovém prostředí například k přejmenování sloupečku „ng_telefon2“ na „ng_adresa“.
3. Změna datového typu sloupečku – NET Genium změní datový typ sloupečku, nebo v případech kdy to není z databázového pohledu možné, zazálohuje data v tomto sloupečku, smaže původní sloupeček, vytvoří nový sloupeček se správným datovým typem, a následně naimportuje zazálohovaná data do tohoto sloupečku – pokusí se data zparsovat ze starého datového typu na nový. Během procesu změny datového typu může dojít ke ztrátě dat, buď zkrácením délky textového řetězce, nebo změnou na nekompatibilní datový typ, například změna desetinného čísla na datum. Následující příklad znázorňuje situaci, kdy je v provozní databázi sloupeček o délce 50 znaků, a ve vývojovém prostředí byl změněn na 250 znaků. Provedením merge se zvýší počet znaků, které je možné uložit do sloupečku „ng_emailprooznameni“. Pokud by se počet naopak snižoval z 250 na 50, znamenalo by to jistě oříznutí dat v provozní databázi!
   

• U výše uvedených změn struktury databáze je důležité znát přesný důvod změny. Buď je vám důvod známý, protože jste změny ve vývojovém prostředí prováděli osobně vy, nebo musíte tuto změnu zkonzultovat s ostatními vývojáři, kteří na vývojovém prostředí pracují. Bez znalosti důvodu smazání sloupečku, změny názvu nebo změny datového typu sloupečku nesmí dojít k provedení importu!
• Mezi změny v databázi patří také změna názvů indexů, která vzniká smazáním staré verze aplikace ve vývojovém prostředí, a následným importem nové verze aplikace do vývojového prostředí. Názvy databázových tabulek a sloupečků jsou identické, pouze se změnily ID editačních formulářů a ovládacích prvků v něm. Tato situace nastává pouze u databázového serveru Firebird, který používá pro názvy indexů ID editačního formuláře a ID ovládacího prvku. Tyto změny jsou zcela neškodné.
  

3.2.2. Merge

• Představuje samotný import struktury vývojové databáze do databáze provozní. Před provedením importu je doporučeno nejprve celou provozní databázi zazálohovat.
• Z pohledu struktury databáze a metadat provádí merge přesně ty SQL příkazy, které jsou uvedené v souboru „SqlBackup.sql“. Tento soubor vzniká při spuštění „merge test“. Strukturu databáze lze tedy v krajním případě narovnat na nový importovaný stav i pomocí tohoto souboru ručně v programu „FlameRobin“ u databáze Firebird, nebo v programu „SQL Server Management Studio“ u databáze MSSQL. Pozor, tímto způsobem ale nelze zkonvertovat data z jednoho datového typu na jiný, pokud je taková konverze součástí merge.
• Možnosti importu databázové struktury dále nabízí několik voleb, které definují, co se má stát s uživatelským nastavením. Toto se týká především portletů, oblíbených položek a sloupců datagridů.

1. User settings from old version – definuje, že veškerá uživatelská nastavení budou zachována z provozního prostředí.
2. User settings from new version – definuje, že veškerá uživatelská nastavení budou přebrána z vývojového prostředí.
3. Delete user settings – veškerá uživatelská nastavení budou přepsána výchozími hodnotami.

• V posledním kroku jsou nabídnuty volby týkající se tiskových šablon:

1. Templates from old version – definuje, že tiskové šablony v provozním prostředí zůstanou zachovány.
2. Templates from new version – definuje, že tiskové šablony budou přebrány z vývojového prostředí.

• Po dokončení importu je vytvářen soubor „SqlBackup.log“. Tento log obsahuje záznam z průběhu provedeného importu.
• Po dokončení importu odstraňte soubor „UnderConstruction.txt“, který naleznete v adresáři „Config“.

3.2.3. Pohledy

• Merge způsobí smazání všech pohledů v databázi
• U editačních formulářů, které mají v poznámce umístěnou definici databázového pohledu, dojde po merge k automatickému znovuvytvoření pohledů za předpokladu, že tento pohled byl před merge z databáze smazán
• U editačních formulářů, které jsou díky merge nově v provozní databázi vytvořeny, je nutné pohled dodatečně vytvořit ručně pomocí funkce „CREATE VIEW”, která je k dispozici v dialogu nastavení editačního formuláře na záložce „Administrace”.

4. Přenesení provozních dat do vývojového prostředí

• Je využíváno pro naplnění relevantních dat do již existujícího vývojového prostředí. Přenesení těchto dat lze charakterizovat kroky:

1. Provedení merge z vývojového prostředí do provozního – aby se shodovala struktura obou databází.
2. Záloha databáze v provozním prostředí – programem „SqlBackup.exe“, volba B (backup).
3. Obnova provozní databáze ve vývojovém prostředí – programem „SqlBackup.exe“, volba R (restore).