Last week I was contacted by one of my Navision collegues. He had performed an upgrade of MS Dynamics Nav 4.0 SP 3 to MS Dynamics Nav 2009.
The problem was a sorting issue in one of the account tables. Before the upgrade, sorting on the “No_” column would be like this:
After the upgrade the same values were sorted like this:
As you might notice, the sorting is very different causing a lot of troubles in some of the reports using data from the accounting table.
My first thought was that it had to have something todo with collation settings of the two database. Examing that however confirmed that the collation was identically configured in the two databases, tables and fields.
I noticed that in the Nav40SP3 version of the database the “No_” fields was defined as sql_variant datatype. In the new Nav2009 database the same field was defined as a varchar field – which would explain the sorting. The problem now was that I could understand the sorting after the upgrade, but I couldn’t understand why it actually worked (was sorting differently) before the upgrade. I tried to manually to change the datatype to a sql_variant in the Nav2009 version of the database – this had no effect at all. I tried scripting the two tables in order to maybe identify any differences in settings or whatever – nothing came to my attention. Having no ideas left to pursue I consulted Microsoft for an explanation and fortunately they presented a solution and explanation very quickly – thank you Gerard Conroy.
Microsoft instructed my Navision collegue to go into the table editor of the accounting table and to view the properties of the field “No.”. In the SQL Data Type property he instructed us to change the value from “int” to “variant”:
- Properties in navision
First of all, let me state that this solved the sorting problem. However looking at the table directly on the sequal server it now turned out that the “No_” field was converted from a varchar to a sql_variant datatype – the exact same thing that I had tried out earlier. Why did it work when performed from within Navision and not when performed directly at the sequal server?
It turned out that when performing this task from within Navision, Navision actually does something more.
When performed directly at the sequal server, something like this is performed:
alter table [CRONUS International Ltd_$G_L Account] alter column [No_] sql_variant not null
In addition to this it turned out that Navision also does something like this (simplified version):
UPDATE [CRONUS International Ltd_$G_L Account] SET “No_”=CAST(“No_” AS BIGINT)
As You might notice, Navision actually performs a CAST of the content of the column – which explains why the sorting turns out differently, since the content is now treated as Bigints rather than character data.
Problem solved – the only thing hauting me, is that I didn’t think of setting up a profiler session to monitor what actually happened when changing this from navision – I won’t forget that again – at least not until next time:-)