UNICODE - Technologický popis převodu, zkušenosti, chyby

[dagmar.mayerova]

Je to vlastně jednoduché. Je potřeba sloupce typů VARCHAR, CHAR a TEXT převést na jejich unikódové varianty NVARCHAR, NCHAR, NTEXT. To se na SQL Serveru udělá příkazem:

ALTER TABLE Tabulka ALTER COLUMN Sloupec UnicodeTyp Nullabilita

Příklad:

ALTER TABLE dbo.TabCisOrg ALTER COLUMN Nazev NVARCHAR(100) NOT NULL

Kde je háček? Háček je v tom, že tento ALTER TABLE projde jen v případě, že na sloupci není "navěšen" nějaký další databázový objekt. Seznam možných objektů je dlouhý, typicky to bývá:

• index
• kontrolní omezení typu PRIMARY KEY nebo UNIQUE (unikátnost)
• kontrolní omezení typu CHECK (kontrolní omezení)
• kontrolní omezení typu FOREIGN KEY (cizí klíč)
• DEFAULT (výchozí hodnota)
• počítaný sloupec téže tabulky
• SCHEMABOUND VIEW nebo FUNCTION (speciální typ pohledu nebo funkce, vzácně se vyskytující)

Takže Helios si při převodu databáze na Unicode udělá seznam tabulek a sloupců, které bude převádět a uschová si definice databázových objektů, které tam "vadí" a poté samotné objekty smaže. Nyní je možné provést ALTER TABLE na Unicode typ. Po převodu všech sloupců se zapamatované objekty do databáze vrátí.

Celé je to naprogramované tak, aby tomu nevadil pád serveru nebo klienta. V případě pádu se pokračuje od místa, kde se před tím skončilo.

Existuje jeden případ, kdy objekt vrátit nejde, a to cizí klíč z tabulky, která není předmětem převodu. Musí to tedy být nějaká tabulka mimo Helios, u které její tvůrce nadefinoval cizí klíč do tabulky Heliosu. V tomto případě cizí klíč není možno vrátit (nesoulad typů) a informace o tomto je zapsána do Žurnálu s příslušným SQL-skriptem, jak cizí klíč vytvořit.

Poznámky:

• Na SQL2000 bude převod vždy pomalejší, protože tam není funkce OBJECT_DEFINITION() a je potřeba SELECT z syscomments, což je vždy pomalejší. Takže doporučuji databázi před převodem na Unicode převést na SQL2005+, bude to pak rychlejší.

• Tabulky, které JSOU předmětem převodu na Unicode:
všechy tabulky Heliosu
+ všechny externí tabulky (pozor, nestačí, že se jmenují TabXXX_EXT, musí být zaregistrovány v Heliosu, že jsou externí)

• Tabulky, které NEJSOU předmětem převodu na Unicode:
Tedy všechny ostatní tabulky, tedy především všelijaká externí řešení. Jako podpora převodu je zveřejněna funkce v rozhraní pluginů. Pluginy postavené na jádru (Core) jsou ošetřeny automaticky.

• Neunikódové typy (VARCHAR, CHAR, TEXT) a unikódové typy (NVARCHAR, NCHAR, NTEXT) jsou vzájemně kompatibliní. To znamená, že starý kód (nepřevedený na Unicode) bude ještě nějaký čas kompatiblní - do okamžiku než zákazník začne používat znaky mimo kódovou stránku 1250 (střední Evropa) nebo si přepne výchozí kódovou stránku Windows. Další možnost, kdy to bude fungovat bez problémů je, že se nepracuje s žádnými textovými daty, ale např. jen s čísly a datumy.

[jan.havranek]

Pokud se při přechodu na UNICODE verzi objeví tato chyba:

SQL Server byl pravděpodobně vypnut nebo přestartován!
211: Possible schema corruption. Run DBCC CHECKCATALOG.

possible_schema_corruption.jpg (34.4 KiB) Zobrazeno 19182 krát

zkuste nejprve ověřit verzi a build SQL Serveru kde převod probíhá.

Tato chyba se opakovaně vyskytla pouze na základním buildu SQL 2005 (tzv. RTM - číslo buildu je 9.0.1399). Microsoft ve svých článcích uvedl, že chyba je odstraněna až po aplikaci SP3, tedy teoreticky se může objevit i na vyšších buildech.

Vždy bylo nejprve ověřeno, zda skutečně nejde o poškozenou databázi (do databáze byly spuštěny SQL příkazy DBCC CHECKDB a DBCC CHECKCATALOG, které nevykázaly žádné chyby).

Pokud není SP3 aplikován, zkuste nejprve provést tento update a poté znovu převod na UNICODE. Pokud se problém nevyřeší nebo pokud příkazy DBCC zjistí nějaké chyby kontaktujte dodavatele systému Helios Orange.

[jan.havranek]

Pokud se po instalaci UNICODE verze během spouštění (při kontrole view) objeví chyba:

Access violation at adress 6F34292F in module ‘Helib2.bpl‘. Read of address 000007D8.

unicode_access_violation.jpg (29.61 KiB) Zobrazeno 19151 krát

pak jde nejspíše o chybu komponenty aplikace, která zajišťuje přístup k SQL Serveru. Výrobce komponenty je o chybě informován a problém se řeší. Bude opraveno pravděpodobně v další verzi Helios Orange (chyba objevena ve verzi 2.0.2009.0912).

Klient s tím nic udělat nemůže a update neprovede. Je nutný návrat na původní verzi Helios Orange a obnova zálohy databáze před updatem.

Chyba se objevuje sporadicky a není třeba se obávat masovějšího výkytu. Konkrétní závislost výskytu chyby na prostředí OS/HW apod. nebyla objevena.