Those who have been working with the Word layout Reporting feature might have heard of the Word add-in called Jet Express for Word. The essence of this add-in is that "... your fields appear in clear text and the search feature makes it quick to add the fields you need", as Jet puts it on their website.

As it's freely available (so at no cost) download it and be happy with it. However I find myself using both Jet Express for Word and the Word XML Mapping pane as the have both their pros and cons. Let me list what I think as pros and cons.

Pros

XML Mapping pane

• When you have inserted a Content Control the focus will (still) be on the layout document, so when you use the arrows it will allows you to move inside the layout and not in the XML Mapping pane
• If your layout already contains content controls you can easily assign an item in the mapping pane by using the Map to Selected Content Control; love it

Jet Express for Word pane

• Adding a content control of an item in the mapping list to the layout can easily be done by double clicking on the item in the list; this is really great

Cons

XML Mapping pane

• Adding a content control of an item in the mapping list is a bit more laborious as you need to right click it and select on the context menu Insert Content Control > Plain Text; this a quite a pain in the ...

Jet Express for Word pane

I guess it's clear there is no winner here. Hopefully either Jet or Microsoft provides us with some improvements here.

Being a Word user from way back 1987 I felt immediately at home when the NAV Core Team did present us MVPs already months ago the Document Reporting feature. I think it's really a great feature. Indeed it has it's restrictions, but it's so easy to use, which is exactly the reason why it has landed in the product. Given a useful dataset definition you will have in no time created the layout. However you might run into the following as I did.

Preparing for a training on the new Document Reporting feature in NAV 2015 I was playing around with various layouts. Pimping built-in ones, using some templates from Office.com and starting from scratch. A couple of times I ran into the issue that the repeater placed on the detail lines of my layout did not show data.

And clearly I had placed a repeater on the table row following the header row of the details:

So why is the Repeater in my WORD Layout not Showing Data? To be honest I do not know. Even Reporting Torben could not tell me exactly. Nevertheless I found out how to fix it or prevent it from happening.

Make sure when inserting the repeater to have a table row above and below it (see the orange colored rows below):

Design

Print

Now it works and just remove the (orange colored) empty rows.

Join the Clean Team!

Welcome to my fellow MVP Alain Krikilion, aka Kriki, who also clearly wants to clean up as you can read below. Let's kriki up NAV!

In the database properties of NAV, on the Options tab, there is the toggle Torn Page Detection.

In SQL2000 this option was introduced to have some mechanism to detect if a page was 'torn'.

What is behind it?

A page in SQL is approx. 8KB. But the default disk-cluster in Windows is 4 KB. So when you write a SQL page to disk, you write it in 2 disk-clusters. If the first cluster is written well, but the second not because of some problem, you have a torn-page.

In a later version of SQL Server, the Checksum was introduced. SQL Server calculates this checksum, when a SQL-page is written to disk, and writes it together with the data in the page. Now when SQL server reads that page, it calculates the checksum and confronts it with the checksum found in the page. If they differ, SQL knows the page is corrupt.

In the beginning, it was feared that it could have a performance impact, but that proved to be wrong (luckily). So the default has become Checksum and you don't need the possibility in NAV to change that as there is no reason to do it!

So lets get rid of Torn Page Detection.

Once I start to clean up ... I can't stop I guess. So here's more that still resides in C/SIDE and has become totally obsolete (the following table is an excerpt from Changes in C/AL Behavior and Support from Earlier Versions of Microsoft Dynamics NAV):

So if it is not supported why still have it? Let's clean up the ...

With RTC all of a sudden, so it seemed to many, AltSearchField was not working anymore. Complaints abundant as probably the same 'many' hadn't learned about the new dropdown list yet. You know that list defined by the FieldGroup property on a table.

Meanwhile this dropdown list has become a common feature that provides the user with even a more powerful way of searching the correct data than AltSearchField did provide. And still AltSearchField is to be found in C/SIDE as a table property including the data that it was populated with in the past. However, totally obsolete now and a next candidate to be cleaned out!

'Vedbaek, go ahead. Clean it out!'