DB2 version 8 understøtter, at data gemmes i UNICODE tegnformat. Det betyder, at nogle tegn fylder 1 byte, andre tegn 2 bytes og i enkelte tilfælde kan et tegn fylde helt op til 4 bytes. Når man migrerer til DB2 version 8 konverteres tegnene i DB2 kataloget til UNICODE. IBM har altså valgt for alle, at nu er det slut med at gemme data i DB2 kataloget i gode gamle EBCDIC tegn. Men betyder det egentlig noget for danske installationer?
Svaret på overstående spørgsmål afhænger af, om man på din installation anvender æ, ø eller å i tabelnavne, kolonnenavne og andre DB2-navne. Og også af, hvad de programmer, der læser fra DB2 kataloget, laver. Hvis man planlægger med at omlægge sine almindelige DB2-tabeller til UNICODE skal man også tænke sig rigtig godt om, for her kan æ, ø og å også volde mange problemer. For almindelige DB2 tabeller har man da heldigvis den valgmulighed at beholde dem i EBCDIC eller ASCII format.
Hele miseren skyldes, at netop æ, ø og å lagret i UNICODE vil fylde to bytes, mens langt de fleste andre tegn, vi benytter i Danmark, fortsat kun vil fylde et tegn. Problemer får man først og fremmest med funktionen SUBSTR, som substring'er på bytes og dermed ikke på tegn. Enhver SUBSTR på en CHAR/VARCHAR kolonne i en UNICODE tabel er dømt til at give problemer, hvis kolonnen kommer til at indeholde tegn, der fylder mere end en byte. Det har IBM selvfølgelig tænkt over, og har introduceret en ny funktion kaldet SUBSTRING , der virker som SUBSTR, bare på tegn i stedet for bytes. Derfor kære læser, gå straks i gang med at lave SUBSTR om til SUBSTRING.
For at holde os udviklere til ilden har IBM sørget for at introducere en fjerde parameter på SUBSTRING, som selvfølgelig skal angives. Derfor er en simpel change all SUBSTR SUBSTRING ikke nok. Her er tre eksempler på brugen af SUBSTRING:
På en almindelig EBCDIC tabel klares ovenstående med en SUBSTR('æøå', 1, 1). Nu skal du pludselig tage stilling til tre forskellige udgaver. Heldigvis kan parameteren OCTETS hurtigt udelukkes, da den forvandler SUBSTRING til en SUBSTR. Desværre kan jeg ikke fortælle dig, om du skal anvende CODEUNITS16 eller CODEUNITS32 som den sidste parameter. Jeg er ret sikker på, at CODEUNITS16 er rigeligt for danske installationer, men jeg kan simpelthen ikke tyde IBM's forklaringer på, hvornår man skal benytte den ene frem for den anden. I øvrigt ser det ikke ud til at give nogen forskel i resultatet for de to parametre.
Før du kaster dig ud i at benytte SUBSTRING, så kan det godt være, at SUBSTRING først virker, når DB2 version 8 kører i såkaldt Enable New Function Mode (ENFM). Når DB2 migreres til version 8 sker det i tre faser. Første fase hedder Compability Mode. Det er ligesom at migrere fra en version til en anden i gamle dage. Forskellen er bare, at alle SQL relaterede nyheder ikke kan anvendes. Næste fase er ENFM, hvor DB2 kataloget laves om til UNICODE, men SQL nyhederne kan stadig ikke anvendes (måske bortset fra SUBSTRING). Sidste fase er NFM (New Function Mode), hvor alle de nye SQL features endelig bliver tilgængelige.
Hvis du har læst så langt som hertil og endnu ikke er gået helt i chok eller ikke helt forstår konsekvenserne af ovenstående, så er jeg sikker på, at chokket nok skal komme. IBM har med DB2 version 8 for første gang formået at introducere en ny udgave af DB2, der ikker er bagudkompatibel. Så snart en DB2-tabel laves om til UNICODE, så risikerer du, at dine programmer ikke længere virker, hvis du ikke aktivt går ind og gør noget. Jeg siger bare god fornøjelse.