Monthly Archives: November 2010

WCF ReaderQuotas problem

Working with WCF I often see errors similar to this:

“An exception of type ‘System.ServiceModel.Dispatcher.NetDispatcherFaultException’ occurred in mscorlib.dll but was not handled in user code

Additional information: The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter The InnerException message was ‘There was an error deserializing the object of type System.String. The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 2, position 40523.’.  Please see InnerException for more details.

This is a quite common issue and is caused by the fact that the message that is being received is too large according to the default configuration of the service binding. As the error description states the solution is to increase some of the values in the ReaderQuotas section of the client web.config file. (Please note that You are able to configure the same on the server side)

A sample web.config file where the ReaderQuotas properties have been set to their maximum values, is shown here:

<binding name=”MyService” maxReceivedMessageSize=”2147483647“>
<readerQuotas maxDepth=”2147483647” maxStringContentLength=”2147483647
maxArrayLength=”2147483647” maxBytesPerRead=”2147483647
maxNameTableCharCount=”2147483647” />
<security mode=”TransportWithMessageCredential”>
<transport clientCredentialType=”None” />
<message clientCredentialType=”UserName” />

You might want to read the documentation for the ReaderQutotas before increasing the values

SQL server sorting problem when upgrading Navision 4.0 SP3 to Navision 2009

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
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:-)


Creating a setup project for a windows service using VS2010

This post assumes that you ar familiar with creating windows services using VS2010 and that You have added an installer to the design view of your service as described in this MSDN article.

Assuming that you have an open solution containing your windows service – do the following to add and configure a setup project:

  1. Right click your solution and choose “add” –> “new project”.
  2. From the menu on the left choose “installed templates” –> “other project types” –> “Setup and deployment” –> Visual studio installer.
  3. Select “Setup project” and put in a suiting name for the project

    add new project screenshot

    add new project screenshot

  4. Setup project screenshot
  5. add project output group

    add project output group

  6. Custom actions

    Custom actions

SQL server row versioning

A client of mine experienced some performance issues with their Dynamics AX setup. In order to analyse the problem I had to determine whether row versioning was enabled or not. Below I will show how determine whether row versioning es enabled or not and how to enable it.

If You want to know more about row versioning, please visit this msdn article about “SQL Server 2005 Row Versioning-Based Transaction Isolation”.

Determining whether row versioning is enabled:

use tempdb
SELECT snapshot_isolation_state, snapshot_isolation_state_desc, is_read_committed_snapshot_on
from sys.databases
where name = ‘my_database_name’

Enable row versioning:

use my_database_name
ALTER DATABASE my_database_name

ALTER DATABASE my_database_name