UNICODE - Technologický popis převodu, zkušenosti, chyby
Napsal: 17.09.2009 13:49Je 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.
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.