Mark Brummel - Author of Microsoft Dynamics NAV 2009 Application Design

Mark Brummel - Author of Microsoft Dynamics NAV 2009 Application Design

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. Stick out tongue

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.

Overhead

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.

 

Posted: 2012-11-14 20:23 by Marq | with 7 comment(s)
Filed under: ,
Bookmark and Share

Comments

Mark Brummel - Microsoft Dynamics NAV Blog said:

I'm currently involved in my first customer/end-user upgrade. It's a system that I implemented

# November 14, 2012 9:45 PM

Erik P. Ernst said:

Hi Mark,

Nice to know about the bug and how to get it. But how to get away with it?

/Erik

# November 14, 2012 9:46 PM

Marq said:

Erik,

What I did was export objects to txt format and do a find/replace of OemCode and OemText with Code and Text.

This worked.

# November 14, 2012 10:06 PM

Mark Brummel - Microsoft Dynamics NAV Blog said:

I'm currently involved in my first customer/end-user upgrade. It's a system that I implemented

# November 14, 2012 10:14 PM

Erik P. Ernst said:

Is there anything else you need to consider when doing this unicode conversion? I mean what if you have a database where the individual companies have been used with different codepages, like one company having English, one Danish and one Thai? Previously this was a sure way to troubles and needed to be handled very special when restoring up. I guess this is easier now, but will it convert correctly?

# November 15, 2012 9:06 AM

kriki said:

> 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.

Are you sure of this?

I also did this as the first step (habbit...), but later it has bitten me back (especially after waiting a lot for the upgrade).

The problem is that in the first step, you need to import objects that contain forms you need to run. So these you can't run any more in NAV2013.

Checking the upgrade manual, it does state that the first step is NOT converting the DB ... but I read that after I converted the DB...

So, first you need to import the first fob in a NAV2009R2 client and run the form and do the first part of the update.

After the step that deletes all objects (except tables), you need to open the DB with NAV2013 and convert it.

# November 16, 2012 5:33 PM

MinhGiao said:

Hi All,

I just posted new topic about Navision 2013 Unicode Fields at

dynamicsuser.net/.../342014.aspx

My company uses default sql locale for Navision 2013 database. No need to change anything for Unicode.

Hope this information can help you!

Best regards,

MinhGiao.

# May 18, 2013 5:57 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)