NAV 2013 | Unicode, OemCode and OemText
I'm currently involved in my first customer/end-user upgrade. It's a system that I implemented myself three years ago with 2009 RTC. Highly (extremely) customized, 50GB and a gazilion interfaces.
The first step in an upgrade, besides merging the objects, is opening the database in the NAV2013 development environment. Previously known as the classic client.
When you do this, first the database should be compatible with SQL 2008. If you upgrade from 2005 this is an option you can set via SQL Server Management Studio.
Then the good old "do you want to convert this database" question pops up. Like Always with upgrades from client to client.
NOTE: Before you do this, all forms and dataports should be removed from the database, which is done by step 1 of the upgrade toolkit.
So what does it do? A lot actually, but the step I wanted to discuss is the upgrade to Unicode.
SQL server supports unicode, but NAV did not use that before, therefore NAV used a datatype on SQL Server that did not support unicode. This is the VarChar datatype. To support unicode youl'd have to implement the nVarChar datatype.
This is done by the upgrade step.
So is this use of Unicode standard?
Yes it is. You cannot use the VarChar datatype anymore, it is automatically replaced by nVarChar.
But there is a bug.
You might run into issues when importing a FOB file that the Text and Code fields are converted to OemCode and OemText.
If you look in NAV2013 you'll see that Text and Code datatypes (both convert in SQL to (n)VarChar) are new optionvalues. The old 2009 values are now OemCode and OemText. This means that you can only store non-unicode or single byte characters in that field.
You cannot choose these options from the dropdown list.
So how do you get to this bug?
If you save a fob that is created with NAV2009 from the import worksheet in NAV2013 and then import it again, you will have OemCode and OemText.
My guess is, this is a bug.
Fortunately I was involved in the beta program and did some testing with Unicode in a CTP build where you'ld have to manually change this, otherwise I would be completely puzzled what this OemCode and OemText was.
This does mean some overhead to SQL Server. Unicode strings use more diskspace and more memory. But my database did not double in size. It grew with about 50%. How much your database will grow depends I guess on the amount of textfields you use compared to decimal fields and dates, etc.