Microsoft Dynamics NAV

Team Blog

  • Microsoft Dynamics NAV Team Blog

    The COPYSTREAM “problem” for Sockets


    I must say that since I started working in the integration area of NAV (from within NAV), I got very interested in the possibilities that it would bring to NAV developers. Back then, I presented a Web Server for the NAS using the Socket ComCom and since then I have seen how people have used the streams and specifically the MSMQ Bus Adapter for integrating services and data.

    When writing the code for the STREAMS (InStream and OutStream), I thought it would be very useful to write a function that could copy from one to another, reading from the InStream and writing to the OutStream. However, when using Sockets, there is an essential problem to completing this task. Since TCP data can contain anything (literally any data), and since the data size is also unknown and un-limited, how can we know when the copying has been completed?

    Recently I was dealing with a problem that I found within one of the communities forums (yes, we are reading) and it was regarding XMLPorts. You need to stream the data to and from them, so I rapidly wrote a codeunit that would allow me to read the XMLPort to a file; for that, I used the COPYSTREAM function to read from the XMLPort to a FILE. A couple of minutes later, I found out that my file was not filled out correctly as it was truncated, and immediately went into the code to further debug the problem. I quickly found out that the problem was that the COPYSTREAM was not reading till the End of Stream (EOS). I was puzzled to find an error in the COPYSTREAM code after all this years, but of course I thought that the call to the EOS was simply missing. Once I saw that the call was in fact there, it finally hit me…. InStream.EOS is not working, or, it cannot really work.

    The real problem here is, how do we know when a stream will not send us more data? Usually this is done through a protocol (like http, ftp, etc) but without a protocol, it is not possible to have a clear rule when we have the EOS. Is it a NULL termination? Is it 2 x CR+LF? Or what about a dot in an empty line? The truth is that, we could make rules, but we cannot have a generic answer to all possibilities.

    Depending on your specific conditions, and specially the size of the data you are sending, you might not see this problem at all. But maybe, from time to time, you have noticed that data being received gets truncated and you are trying to figure out what went wrong.

    To further illustrate the problem, let’s receive a file using Sockets and Save it on our local file (I’ll skip the sending code unit, but it can very easily be done following the samples provided in the Development Guide for Communication Components):

    COPYSTREAM for Sockets


    In the environment where I am writing this, I can send files without any issue up to approximately 25 Kb. After that, everything seems to work fine, except that the file gets truncated, that is, I am trying to send a 48 kb file, but get a truncated one.

    In order to get rid of this problem, I suggest copying the stream one char at a time, so the code could look something like:

    'COPYSTREAM' time based.

    The retry is necessary, because we cannot rely on InS.EOS. InS.EOS also suffers from the fact that we don’t know when the stream will stop sending us data.

    A nicer way to deal with this would be to first send how big the data is. That way, we don’t have to rely on time to assume that the information has indeed completed its transmission. If you are sending XML documents, you could also use the DOMDocument.load(InS) return value, to see if the received data indeed contains a valid XML document. If you have access to codeunit 7700, you can see an example on how this could be achieved (as you need to first copy the stream).

    Of course, as mentioned before… This issue will only happen with the raw SocketBusAdapter.

    Jorge Alberto Torres (jtorres)
    Software Developer Engineer

  • Microsoft Dynamics NAV Team Blog

    What are the Visual Studio options for developing RDLC reports for Dynamics NAV 2009


    Updated 24. September 2009 to include options for Dynamics NAV 2009 SP1. / Claus Lundstrøm

    Today we have the following outlined in our Online Help

    For development of reports for the RoleTailored client, one of the following products is required:

    · Microsoft Visual Web Developer 2005 Express edition SP1 or above

    · Microsoft Visual Studio 2005 Standard or Professional SP1 or above

    · Microsoft Visual Studio 2008 Standard or Professional or above

    Note: If Microsoft Visual Web Developer 2005 edition is used, the Reporting Add-In for Microsoft Visual Web Developer 2005 is also required.


    I would like to elaborated on this because other version are also available and we also have a hotfix available for Microsoft Visual Studio 2005 users which need explaining.

    So here it goes. The following editions of Visual Studio are supported:

    Microsoft Visual Studio 2005 Editions:

    · Microsoft Visual Web Developer 2005 Express edition with SP1. With “Reporting Add-In for Microsoft Visual Web Developer 2005

    · Microsoft Visual Studio 2005 Standard or higher editions with SP1

    Tip: If SP1 is not installed for any of the 2005 version you will be asked to convert report when opening Visual Studio from Classic Client. Converting the report will not do any good, so SP1 is required.

    Note: Visual Studio included in SQL Server 2005 is not supported.

    Microsoft Visual Studio 2008 Editions:


    Note: ZIndex hotfix is included in SP1 for Visual Studio 2008. ZIndex hotfix issue explained  in the end of this blog post.

    Note about Microsoft Visual Web Developer 2008 Express Edition: NOTE: ONLY IF YOU ARE USING DYNAMICS NAV 2009, SINCE THIS HAS NOW BEEN FIXED IN RELEASED SP1
    Unfortunately this does not work out of the box with NAV 2009 RTM, since “Microsoft Report Viewer Add-on for Visual Web Developer 2008 Express Edition” was released after NAV 2009 RTM.

    When using Visual Web Developer with Report Viewer Add-on, you will be asked to convert report when opening Visual Studio from Classic Client. Converting the report will not do any good.

    There is a workaround for this:

    1. Navigate to “C:\Program Files\Microsoft Dynamics NAV\60\Classic”

    2.  In this folder there is 2 folders called “ReportLayout2005” and “ReportLayout2008”

    3. Copy all files from “ReportLayout2008” to “ReportLayout2005”

    Doing this will of course kill support for “Microsoft Visual Studio 2005” and “Microsoft Visual Web Developer 2005 Express” on this specific client, but now Visual Web Developer 2008 works, and you no longer get the convert report message. We plan to have this issue resolved in SP1 for Microsoft Dynamics NAV 2009, so there is no need for this manual workaround.

    ZIndex issue:

    • Without ZIndex hotfix:

    When making any change to a report in Report Designer(Visual Studio) all ZIndexes will be updated in the RDLC.

    • With ZIndex hotfix:

    When making any change to a report in Report Designer(Visual Studio) only ZIndexes for the specific change will been updated.

    Having the ZIndex hotfix installed will make comparing of changes in between version of a report easier.

    Hotfix works for all Visual Studio 2005 versions. ZIndex hotfix is included in SP1 for Visual Studio 2008, but please notice that hotfix is not available in Visual Studio 2008 without SP1.

    Read more about the ZIndex hotfix for Visual Studio 2005, and how to obtain here.


    Claus Lundstrøm, Program Manager, Microsoft Dynamics NAV

  • Microsoft Dynamics NAV Team Blog

    Using SQL Server 2008 Express


    Small tip, if you want to use SQL Server Express 2008 instead of SQL Server Express 2005 which is included in the Microsoft Dynamics NAV 2009 RTM installation, here is what to do:

    The Demo installation of NAV 2009 RTM is looking for a instance called MSSQLSERVER, so if this is not detected during install, SQL Server Express 2005 will be installed, and Demo Database will be attached to SQL 2005 even though you might have had SQL 2008 Express installed.

    So to avoid this set the Instance to MSSQLSERVER on the SQL Server 2008 Express. This way SQL Server 2008 Express will be used and SQL Server 2005 will not be installed.

    Note: SQL Server 2008 requires the following:

    .NET Framework 3.5 SP1
    Windows Installer 4.5
    Windows PowerShell 1.0 (Included in Windows Vista SP1 and Windows Server 2008)


    Claus Lundstrøm, Program Manager, Microsoft Dynamics NAV

  • Microsoft Dynamics NAV Team Blog

    Upgrading Application Objects - Tips


    Some partners use the Merge tool in the NAV Developer Toolkit to attempt to merge the FULL set of objects from the old and new versions. This is not necessary and often will cause more problems than it is worth.

    For the purpose of discussion, let's say that you are upgrading a database from version 3.70 to 5.0 SP1.

    One common error that occurs is something like this...

    Your program license does not permit you to delete the IC Partner Code field in the table.

    The IC Partner Code field is a field that did not exist in 3.70 but has been added to the 5.0 SP1 database. Most often what we find is that partners are mistakenly trying to import the merged objects into the Customer's database when they receive errors like this. The new fields for 5.0 SP1 do not exist in the customer's database. You will not be able to import the merged text file that you created from the Developer's Toolkit into your customer's database. You must first import the text file into a base Cronus 5.0 SP1 database. Once the import has completed successfully, you will then export all the objects from this database as an fob file, and then you will be able to import the fob into your customer's database.

    These program license errors also occur if the object merge is not handled correctly. The main thing to keep in mind is that there will be fields that existed in 3.70 that do not exist in 5.0 SP1 and new fields in 5.0 SP1 that did not exist in 3.70. A partner license will not permit you to delete or create fields in the NAV reserved range. However, this SHOULD NOT be a problem if the object merge is done correctly. Keep in mind that if there have been NO modifications to an object, then there is no need to import a merged version of that object into 5.0 SP1. Any data from 3.70 that needs to be converted will be handled during the data conversion part of the upgrade process. When you run step 1 of the upgrade toolkit, the data that needs to be converted will be moved over to temporary tables and then converted during step 2.

    Concentrate on your modified objects. If you are going to use the NDT to perform the merge, try working with only the modified set of objects rather than trying to merge every object in the database. As a matter of fact, it will often be faster to manually re-enter your modifications in the base 5.0 SP1 database than to try to track down all of the errors that can occur with the merge. One option is to use a text compare tool to compare the base 3.70 unmodified table to your modified one, then manually copy and paste your modifications into 5.0SP1. The NDT function Compare Two Versions works well for this purpose. TIP: Make sure before you do a text compare that the language layers in the "Old Base Version" match the "Current Custom Version". This will prevent having nearly every object show differences in the Compare Tool due to captions...

    Open a clean Cronus database for your Old Base Version.
    Go to Tools/Object Designer.
    Go to Tools/Language Module/Export
    Select a file name on your computer for the export in case you should need it at some time in the future.
    Select one of the languages that you do not want and then be sure to click the Delete Language text box. Select OK.
    Repeat for each of the languages that you do not need.

    Another thing to keep in mind when using the Merge Tool in the Developer Toolkit is that you usually cannot just Accept All Changes with a set of customized objects, because there are almost always conflicts in code that must be resolved manually. Many developers prefer to use the Compare tool in the toolkit and then copy and paste the changes manually into the new version. Compare and Merge is a tool for developers to use as they see fit, but it is not flawless, so you should always check the suggested changes and resolve any conflicts manually.

    Laura K. Lake (lalake)

    Microsoft Dynamics NA

    Microsoft Customer Service and Support (CSS) North America

  • Microsoft Dynamics NAV Team Blog

    Dynamics NAV 2009 and MS Office Integration, send-to Excel and Word


    This blog describes changes in office integration feature, send-to Excel and Word, when using RTC client in NAV 2009. 

    Send-to menu option on RTC client is typically located in menu, under Actions - Send to option. Shortcuts for this functionality is added, but unlike version 5.0, only send -to Word and Excel options are available.

    To export any page to Word/Excel, open the page and in Actions-Send-to menu select Word or Excel. The style sheet selected as default for that page/all pages will automatically be selected.

    Codeunit 403 is no longer called by client when selecting these options, so any customizations of this process will not be used by RTC. This also means the Style Sheet tool can not be used with RTC.

    There are no changes to this functionality when running with Classic client for NAV 2009.


    Jasminka Vukovic (jvukovic)

    Microsoft Dynamics NO

    Microsoft Customer Service and Support (CSS) EMEA

  • Microsoft Dynamics NAV Team Blog

    Start Your Search Engine: Microsoft Dynamics NAV 2009 Developer and IT Pro Help Is On MSDN


    The big news today is that we’ve released the updated developer and ITPro docs to the Web to make it easier for you to search and find information. You can find the updated docs in the MSDN Library. This update builds on the content that shipped with NAV 2009 and includes new or revised developer, installation, and administration topics around:

    • Security for the RoleTailored client
    • Differences between developing for the Classic client and the RoleTailored client
    • File Handling
    • C/SIDE Reference

    As Claus Lundstrøm blogged about last week, we posted the updated Microsoft Dynamics NAV 2009 documentation for developers and ITPros to the Microsoft Download Center.

    As Claus mentioned in his post, the updates don’t end here. We’re writing new content every day and plan to refresh the Download Center and the MSDN Library about every 3 months. Here’s how you can help us — we need your input on the content that you want to see in the next update. There are a couple of ways you can provide this feedback:

    • If you’re using nav_adg.chm, cside.chm or nav_install.chm, click the MSDN Documentation Feedback link at the bottom of a topic. That sends your request by e-mail directly to our inboxes.
    • If you’re using the MSDN Library, click Click to Rate and Give Feedback in the top right corner of a topic. That sends your rating and content request to a database of requests that we will review regularly.
    • Add a comment to this blog post.

    In addition to the developer and ITPro doc updates, the Microsoft Dynamics NAV 2009 UX Guide is also available from the Microsoft Download Center. The UX Guide is a tool to assist Microsoft Dynamics NAV ISVs in building more user-friendly applications that match the standard Microsoft followed to create the RoleTailored client.


    Bob, Jill, Elona, Susanne (the Microsoft Dynamics NAV 2009 Platform Writers)

  • Microsoft Dynamics NAV Team Blog

    Automation Objects in Microsoft Dynamics NAV 2009



    The Automation object is often used to integrate NAV business logic with external processes and thereby extend the functionality of the product, such as integration with other products like Office. Automation objects must expose a COM interface, and every time we cross a process boundary is worth thinking about performance, but issues that involve correct operation could have a negative impact on performance. This is something we are willing to accept. One example is that objects designed for a single thread execution must execute on Single Threaded Apartment (STA) threads. Having a look at this KB article ( explains why office products never should be allowed to run on the server:

    Reentrancy and scalability: Server-side components need to be highly reentrant, multi-threaded COM components that have minimum overhead and high throughput for multiple clients. Office applications are in almost all respects the exact opposite. Office applications are non-reentrant, STA-based Automation servers that are designed to provide diverse but resource-intensive functionality for a single client. The applications offer little scalability as a server-side solution. Additionally, the applications have fixed limits to important elements, such as memory. These cannot be changed through configuration. More importantly, the applications use global resources such as memory mapped files, global add-ins or templates, and shared Automation servers. This can limit the number of instances that can run concurrently and can lead to race conditions if the applications are configured in a multi-client environment. Developers who plan to run more than one instance of any Office application at the same time need to consider "pooling" or serializing access to the Office application to avoid potential deadlocks or data corruption.”



    Flavors of COM

    Apartment threading

    There are two major flavors of Automation objects, ones that are designed for single threaded applications, and ones that execute well in a multithreaded environment. This doesn’t prevent one from running STA objects on the server and MTA objects on the client, but each scenario where “best practices” are deviated should be considered closely.

    An example would be the XML Document object


    The DOMDocument is a single threaded apartment version and the FreeThreadedDOMDocument is the version that utilizes a multithreaded environment, like the server. But in cases where we a free threaded version of the object is not available, it would properly be acceptable to use the version available, because the .Net runtime is managing MTA-to-STA marshaling behind the scene. This could result in bad performance and other problems – but in most scenarios it is likely to work. A closer look at “PRB: MSXML Performance Bottleneck in ShareMutex Under Stress” explains why issues like these must be considered.

    “Using the MSXML parser in a high-stress environment … may cause unusually long run times on XML requests, and the application or service can appear to stop responding (hang).“

    And the solution in this scenario would be to use the FreeThreadedDOMDocument object on the server.

    Native and Managed Automation Objects

    The Automation implementation in the Role Tailored Client and the Dynamics NAV Server utilizes the CLR implementation, and the CLR does an excellent job of allowing managed code to call out to unmanaged Automation objects. It generates a runtime-callable wrapper (RCW) proxy that implements all of the interfaces of the underlying object. Furthermore, the CLR has a built-in mapping/marshaling layer that knows how to translate the types between the native and managed domains.

    The following table shows the specific type mappings between AL, COM and their corresponding .NET types.


    All the Automation objects are late bound activated; this means that they must implement the IDispatch interface, in order for the Reflection API to be able to invoke members. Managed Automation objects are recognized by the RCW as being managed and standard CLR reflection invocation takes place. Therefore, in-process (dll) and Out-of-process (exe) Automation behaves identically if the objects are created in a managed language.


    The default account for running the NAV Server, configured at installation time, is the built-in Network Service account. This account does not have permissions to spawn a new process, as configured in Component Services, and it is not recommended to change that behavior. This is by design, in order to prevent out-of-process Automation servers (Executables with a COM Interface) to execute on the server. But if the scenario requires this, it would be a recommended practice to create a new service account with the minimum privileges plus the “Launch and Activate Permissions” of the required Automation Servers. These processes will then be created on the server and properly stays alive until they receive a specific terminate command, or the server is rebooted. Another risk with Automation servers on the NAV Server machine is that users could potentially share the same Automation process. In AL, the construct CREATE (automationServer, TRUE), will search the system for created instances of type “automationServer” and try to reuse that process, and potentially read data created by another user.

    Therefore the recommended syntax would be CREATE(automationServer, FALSE, FALSE), for Automation servers running on the NAV Server. On the client tier, no sharing can occur and it would be perfectly fine to try and reuse the Automation server.

    The in-process Automation objects whether they are created on the client or server tier are hosted by the running process and inherit the security context of the active user. The same goes for OCX controls that require an UI and therefore only will be allowed on the client side.

    Wrap-up (recommendations)

    Server tier
      • Native Automation objects: In-process automation servers, like MSXML6.dll.
      • Objects with a user interface such as OCX types.
      • Managed wrapped COM Objects
      • Objects designed for multi threaded execution (MTA)
    Client tier
    • Native Automation objects: Out of process automation servers, like Microsoft Office.
    • Objects with a user interface such as OCX types.
    • Objects designed for single threaded execution (STA)
    • It is good practice to design your Automation interfaces to get as much work done in a single method invocation. And when consuming a component, try to use it in way that minimizes chattiness. This is utmost importance for the client side automation scenario.


    COM is an immutable, interface-based model. Interface design is very important and should always be split from the implementation. Try to avoid auto-generated interfaces based on classes as they have a tendency to violate this guideline and not version well. There is a good source of information at: “Do not use AutoDual ClassInterfaceType“


    (see the first comment on this post for the text of this sample)

    - Stefan Omdahl

  • Microsoft Dynamics NAV Team Blog

    Microsoft Dynamics NAV 2009 Ships!


    A week ago, the Microsoft Dynamics NAV team celebrated the launch of version 2009, a product that involved over three years of work.  We had a party on the MDCC campus (which subsequently ended up in an Irish bar somewhere in Copenhagen) and spent some time talking about our accomplishments.  The energy in the room was infectious.  We signed the ship poster, a tradition at Microsoft, previewed the Microsoft Dynamics NAV demo for Kirill's keynote at Convergence EMEA, and announced that we'd take a team day off – these all helped people savor the moment.  Though we hit many bumps along the way during those three years, we finished with what it is nothing short of a landmark release.  So, if you're an NAV fan and it's Friday night for you, toast to this release, because it's an event to remember!

    In this blog post, I'd like to tell the story of Microsoft Dynamics NAV 2009.  Instead of resorting to sanitized marketing sound bites, this will be a more personal account.  It's my own particular point of view exploring this product and how it relates to our customers and partners.

    There are a number of things that I simply love about this release, but I have to start with the UX (or user design).  When I installed NAV 2009 when I first joined the team back in February, I knew the user experience was special.   Then, in my last blog post, I admitted that I had a crush on it.  Now, I must say that it's brilliant.  To understand why, I have to make a brief detour.

    At the heart of a good business solution is the resulting productivity of its users.  How much time does the system save?  How much higher is the quality of their work?  Because we are engineers, we at MBS needed a business productivity framework to understand how to improve it with our products.  Together with a research firm, we concluded that end user productivity had to take into consideration familiarity, ease-of-use, business insight, collaboration, and flexibility in addition to transactional efficiency (what we typically think about when we think about productivity).  As I started to learn more and more about the Dynamics NAV 2009's user experience, I realized just how well it captured all these characteristics.  It is familiar – Role Centers make users feel at home with the data and work they see upon entering the product; it is easy to use - Activities and the Action Pane make it very apparent how things are done and what needs to be done; it provides insight through integrated reports and data that are showcased in the context of actions to be taken; it makes collaboration easy through notifications and by working well with Office; it is flexible - personalizations permeate the experience and are very simple to make; and, finally, it is efficient - keyboard shortcuts and data positioned well with actions make performing tasks fast. 

    But this isn't brilliant.  This isn't a work of art.  This is just good engineering.  What makes the user experience brilliant is that users fall in love with it.  I recall an email thread I had with Jakob Nielsen, our Director of UX, sometime this past summer.  In a larger forum, he was talking about getting our customers to have an emotional connection to our user experiences.  I thought, "What's he talking about?"  I joked, "What's he smoking?"  But over time, it sunk in.  And then last week, I saw a video from a customer that had just recently gone live with Microsoft Dynamics NAV 2009 as a part of our early technical adoption program (TAP).  In the footage, a warehouse manager showed off his Role Center and asked the Director of Operations for the company, "Can I keep it?"  Here was a person who was emotionally attached.

    People who love the tools they work with end up loving their work more.  People who love their work more end up being more successful.  They make fewer mistakes, they treat each other better, and they get to work on time.  If we build a Microsoft Dynamics NAV user experience that users love, it's a win-win-win situation.  The customer wins.  The customer's employee wins.  And we at Microsoft win.  That's why this user experience is brilliant.

    Of course, Microsoft Dynamics NAV 2009 has a lot more to it under the hoods.  If you're an engineer, you can sense when a software product is getting "brittle."  Just like a bridge that has had too much stress over time and suffers metal fatigue, so too does software age if it isn't refactored over time.  Entropy creeps in as code is added that doesn't adhere to the original design principles or doesn't meet the original quality bar (assuming this existed).  For 2009 we've made a conscious effort to modernize the core architecture.  For instance, in addition to giving the user experience a new look and feel, we've also built it from scratch on .NET.  It has a modern, modular architecture that will help us introduce new innovations in the future quickly and without compromising quality, innovations such as a new "channel" like Sharepoint or new visualization controls that are based on the dynamic capabilities of Silverlight or WPF.  We've also made the architecture 3-tier from a 2-tier fat client.  In addition to improving security, such as running the business logic from one, trusted place, this change gives partners the ability to do application-to-application integration much more easily with web services.  With a click of a button in C/SIDE, a new web service is exposed for consumption.

    On the server tier, we've taken advantage of .NET once again.  C/AL business logic written in C/SIDE now compiles down to MSIL via a C# transformation.  Consequently, we leverage the innovations that the .NET runtime team has worked on for the past eight years.  This frees our team up to focus on problems more closely related to ERP.  As I've already mentioned for the client and the server, we've taken advantage of Microsoft's world class platform stack, particularly with .NET.  But we've also done this with SQL reporting services, which are now our tool of choice for charts and table reports that can be viewed in context in the user experience.  In summary, these architectural investments have a tremendous impact on this release and future releases.  Good, modern architecture gets the best technology in your hands over time and maintains high quality.
    It's true that this release has largely been about technology.  That was intentional.  We made a commitment to modernize the product, and from our perspective, we're probably two-thirds done. We’ve finished the hard parts and the ones that impact partners and customers the most: the user experience, reporting, and the tiered architecture.  We recognize that a fine balance must be made between innovation on the one hand and maintaining partners' and customers' investments on the other hand.  There is no perfect formula here.  Sometimes there are innovations that break changes that our customers and partners have made.  In these cases, you have a couple of strategies to minimize the pain - you make the innovations "opt-in" and you create tools and provide support for completing the transformation.  In Microsoft Dynamics NAV 2009, we've done both.

    We allow our customers to run the "Classic" client and the RoleTailored client concurrently.  This gives customers flexibility to move their users to the RTC over time.  In addition, we've made sure that "Classic" reports, the most common customization that customers create, run in the RoleTailored client, so they do not have to be converted to SQL RS reports if the customer doesn't care to take advantage of RS's capabilities.  As I mentioned before, the business logic in Microsoft Dynamics NAV 2009 is converted from C/AL to MSIL via C#.  Though the runtime has changed, the actual code itself has not.  This means that business logic changed or added by partners and customers is protected and migrates to the new version as-is.  Finally, for partners, we've maintained the C/SIDE development environment, extended it with a page designer, and provided tools for converting "Classic" forms and reports to pages and RS reports, respectively.

    Perhaps the thing I'm most proud about in this release is that we’ve substantially improved its quality.  We're upping the bar considerably in a number of ways.  The clearest indication is with the TAP and the Beta Access Program (BAP).  As a result of these programs, we have 9 customers already running Microsoft Dynamics NAV 2009 in production, and over 80 different partners, including ISVs and implementers, trained and familiar with the new version.  My favorite statistics are these - we have over 1 year of server uptime without a crash reported and over 135 user-months on the RoleTailored user experience.  These should give you an indication of the stability and the attention to quality that we've paid on the release.  There are a number of other quality initiatives and investments that we've made, including improving our stress test environment, improving our code coverage and automation, and testing on 100 configurations of the operating system, database, and other system elements.  We think you're getting the highest quality NAV product yet.

    As you can see, for me the story of Microsoft Dynamics NAV 2009 is one of tremendous success.  The value proposition of end user productivity is core to our vision and very compelling to our customers.  The investments in modernization of the architecture set the stage for innovation and product improvements in the future.  The attention to partner and customer investments has made this release the best in terms of readiness.  And the quality achievements have set the bar higher than they've ever been.  While this is not a perfect release - it will require partners to learn new concepts like RoleTailored computing and new tools like the Reporting Services designer, it is one that I believe takes Microsoft Dynamics NAV, our partners, and our customers into a new, modern era of ERP!  I hope that you're checking it out!

    - Dan

  • Microsoft Dynamics NAV Team Blog

    Using variables and C/AL code in a report in NAV 2009


    This previous blog "NAV 2009 - The structure of reports in VS report designer" describes how to get data from your data items into the layout of a report in Visual Studio (VS) report designer. This time we look at how to control the iterations of a report with code, and showing variables rather than fields on a report. So, for when you manually want to control what to print.

    The tricky part is really to get the structure of the report right. Once this is done, adding additional information from variables / controlling data items from code, is not much work - mainly for these reasons:

    • The data flow in the report is still done from data items, which means the old way.
    • To show variables on a report, you just add it to sections, and it automatically becomes available from the VS report designer.  

    This example shows how to:

    • Use code to control the number of iterations on a data item
    • Show variables on the report
    • Add options to the request page, so user can tick “show Details”


    Control data flow from code

    This is really the same as it has always been. Just use C/AL code on data item triggers to decide how many iterations / whether to print a record or not. For this example, we will just print integer numbers. So to begin with, make a new report with the following two data items:

    Integer -  DataItemTableView = SORTING(Number) WHERE(Number=FILTER(1..3))
      Integer (name it Int2), and indent it under the first one. Don’t specify further properties for this data item – we will control this from code. The report should look like this:


    As I am sure you realise, without filtering on the Integer table the report becomes very long! So, to restrict the second data item to print just 5 numbers, just do it as you would normally from C/AL code:

    Int2 - OnPreDataItem()

    This is really all you have to do to manually control what data is printed. As mentioned already, this is not different to how it has always been.
    So now we just need to complete the report to print these numbers. This is where it can get more tricky if you are new to tables in VS report designer. For further details about the next steps, refer to this post.

    First, to make data available in VS report designer, add it to the sections:
    Go to View -> Sections, and add Number for each of the data items (Integer.Number and Int2.Number) from the Field Menu. It doesn’t matter where on the sections you add it.
    Then, finally open VS report designer (View -> Layout) to put the numbers on the report. In VS report designer, add a table. Insert a group by right clicking on the icon for the Header:


    Set the group to have Expression = “=Fields!Integer_Number.Value”, and untick “Include group footer”. Then put Integer_NumberCaption into the header, Integer_Number.Value into the Group Header and Int2_Number.Value into the Group Details, like this:


    The report should now print 3 times the numbers 1 – 5:



    Adding variables to the report

    Now, instead of printing records from the two data items, create a variable and assign it values dynamically. Create a new global variable called TextVar, type Text, then assign it some value, for example like this:

    Int2 - OnAfterGetRecord()
    TextVar := 'Num ' + FORMAT(Number);

    Again, just like you are used to. All you have to do from here, is to add it somewhere to sections to make it available in VS report designer.

    In many cases, a report is designed to be run from either the classic client or the Role Tailored Client (RTC), and you need to add something to sections just to get access to it from VS report designer, but you don’t want it to show when the classic report runs the report. In this case, just set Visible=False, and the classic report won’t show it. In places in the standard application where this is done, the property ForeColor has also been set to 65535 (Yellow), just to mark that this field is only there so that it can be used in the VS report designer. For example, look at sections for report 116 – Statement.

    Adding options to a request page

    In the classic report designer you have request forms. In reports for RTC, you have request pages. To add something to a request page, go to View -> Request Page, and you are in a normal page designer. For this report, add a variable called HideDetails (Boolean) to the request page like this:


    Note that Type is “Field”, whether SourceExpr is an actual field, or as in this case a global variable. Again, to make it available in VS report designer, you must add the variable to the sections. Then go into the layout in VS report designer.
    To hide a section from the table, use the Visibility-tab for the section. Right click on the Details section in the table, then Edit Group, and on the Visibility tab set Visibility to Expression, and the expressions to =Fields!HideDetails.Value:



    The end result is, that now when printing the report from RTC, you have the option to Hide Details.




    Lars Lohndorf-Larsen

    Microsoft Dynamics UK

    Microsoft Customer Service and Support (CSS) EMEA

  • Microsoft Dynamics NAV Team Blog

    Dynamics NAV and export to Excel: Export dates as true excel dates


    When running Send-to Excel functionality and exporting data to MS Excel using style sheets, all data exported form NAV is formatted as either numbers or strings.

    That also includes dates, that are exported as strings and not formatted as true dates in excel. As of update 1 for NAV 5.0 SP1, data.xml generated when running export to excel contains data type attribute for each row with data printed. Using 'Date' attribute, one can add a fromatting rule in the style sheet, to specify formatting of data of type Date.

    Following example illustrates this. Please note, the style sheet below is created and tested on W1 NAV using US regional settings. Though tests have been run on few other combinations of regional settings and date format, you might need to adjust the rule to local date format.

    To represent strings as dates in excel, .xml file generated must contain dates in XML datetime format. XML format is defined as:


    The scenario also assumes years in Dynamics NAV are represented with 2 digits,  and years in range 00..29 are in fact 2000..2029, while years in range  30.. will be formatted as 1930... Dynamcis NAV date format in this example is mm/dd/yy.

    In the coded below, substring(@value,1,2)=mm, substring(@value,4,2)=dd and substring(@value,7,2)=yy

    Modify the code in example below according to date format in local NAV client. 

    To modify the style sheet, open the default style sheet for export to Excel using notepad. The default style sheet is NavisionExportToExcel.xslt, and is placed in Stylesheet folder of the Client folder.

    Go to line 61 of the default style sheet, or locate the section below using Search/find, and add the lines marked in the code below.



    Style ss:ID="CheckBox">   

    <Alignment ss:Horizontal="Left" ss:Vertical="Bottom"/>

    <Font ss:FontName="Verdana" x:Family="Swiss"/>


    <Style ss:ID="rowheading">

    <Font x:Family="Swiss" ss:Bold="1"/>

    <Interior ss:Color="#C0C0C0" ss:Pattern="Solid"/>



    Style ss:ID="Dateformat">    <!-- THIS LINE IS ADDED !-->

    <!-- this is where we define the style for date type fields!-->


    NumberFormat ss:Format="Short Date"/>    <!-- THIS LINE IS ADDED !-->


    Style>   <!-- THIS LINE IS ADDED !-->



    Go to line 235 of default style sheet, or locate the section below using Search/find, and add the lines marked in the code below.



    xsl:template match="Control[@type='TextBox']">


    Cell xmlns="urn:schemas-microsoft-com:office:spreadsheet">


    <xsl:when test="(@datatype = 'Date')">      <!-- THIS LINE IS ADDED !--><!--  Dateformat style is to be used for data type Date !-->

    <xsl:attribute name="ss:StyleID">Dateformat</xsl:attribute>    <!-- THIS LINE IS ADDED !-->

    </xsl:when>   <!-- THIS LINE IS ADDED !-->

    <xsl:when test="(@datatype != 'Integer')and(@datatype != 'Decimal')and(@datatype != 'BigInteger')">

    <xsl:attribute name="ss:StyleID">TextBox</xsl:attribute>







    <!-- The actual date formatting, make sure data sent from navision are formatted according to XML datetime format  yyyy-mm-ddT00.00.000 and passed as dateTime type of variable. This makes sure Excel will consider this as date type value. Excel will from here take input data and format the output in the format selected in regional settings (or excel settings) !-->

    <xsl:when test="(@datatype = 'Date')and (substring(@value,7,2) &gt; 29)">  <!-- THIS LINE IS ADDED !-->

    <xsl:attribute name="ss:Type">DateTime</xsl:attribute>    <!-- THIS LINE IS ADDED !-->

    <xsl:value-of select="19"/><xsl:value-of select="substring(@value,7,2)"/>-<xsl:value-of select="substring(@value,1,2)"/>-<xsl:value-of select="substring(@value,4,2)"/>T00:00:00.000</xsl:when>  <!-- THIS LINE IS ADDED !-->

    <xsl:when test="(@datatype = 'Date')and (substring(@value,7,2) &lt;= 29)">  <!-- THIS LINE IS ADDED !-->

    <xsl:attribute name="ss:Type">DateTime</xsl:attribute>  <!-- THIS LINE IS ADDED !-->

    <xsl:value-of select="20"/><xsl:value-of select="substring(@value,7,2)"/>-<xsl:value-of select="substring(@value,1,2)"/>-<xsl:value-of select="substring(@value,4,2)"/>T00:00:00.000</xsl:when<!-- THIS LINE IS ADDED !-->

    <xsl:when test="(@datatype = 'Integer')or(@datatype = 'Decimal')or(@datatype = 'BigInteger')"

    <xsl:attribute name="ss:Type">Number</xsl:attribute>

    <xsl:value-of select="@value"/>



    <xsl:attribute name="ss:Type">String</xsl:attribute>

    <xsl:value-of select="@value"/>




    These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.

    All feedback providing scenarios where this change wouldn't work, or scenarios that would require any other formatting of date type fileds, is most welcome.


    Jasminka Vukovic (jvukovic)

    Microsoft Dynamics NO

    Microsoft Customer Service and Support (CSS) EMEA

  • Microsoft Dynamics NAV Team Blog

    NAV 2009 - The structure of reports in VS report designer


    One thing is to make a report look pretty. But before you can do that, you have to make it work first. This post is about how to get the data structure right when designing reports in VS report designer for the new client in NAV 2009.

    If you are completely new to the new environment, then take a look at this post first:

    NAV 2009 - Report Designer - Introduction to the new environment

    This post also assumes that you are already familiar with designing reports in the classic report designer.

    Start with a classic report

    The new environment in Visual Studio (VS) report designer relies completely on the data structure you define in the classic report designer. So you must first design data-items and link them in the right way. You must also use the classic report designer to decide what to display on the report – but not where to display it. Only data that you add to sections in the classic report designer is available in VS report designer. You can add fields and other data wherever you like in sections – as long as the data is there. Then you use VS report designer to place the data where you want it. 

    Sections in VS report designer - 1 Header, 1 Body and 1 Footer

    A report in Visual Studio always has exactly 1 Body section.  You cannot add more than 1. Optionally it may have 1 Header and 1 Footer. You cannot add further headers or footers.
    Enable Header and Footer sections by right clicking in a blank area, then enable / disable header and Footer section:


    Warning: If you disable the Header Footer  the section with all its content will be deleted.
    When the report runs, it will run the Header section once, then the Body section once, and then the Footer section once. It will not – like in the NAV report designer – run the Body section for each iteration / record. Looping through records is done by creating a table in the body section. So understanding tables is really important to getting the right data in your report.

    This is there we loop through the data in a report. To create a table, insert it from the toolbox. As default it will have a Header, Detail and Footer section.
    To enter something in a cell, either right click it, select Properties, and specify Value. Or drag and drop items from your Data set. Remember that your data set (“Website Data Sources”) consists of what you have added to the sections in the classic report designer.

    Table Sections:
    This is a typical place to put captions. If you drag an item containing text from your data set into a header, the environment automatically adds “First” to it. “First” means that it will show the first value in the data set, as opposed to looping through each record in the data set.
    This is where you have the iteration of the data in the report.
    This is a typical place to put totals. If you drag an item containing a numerical value from your data set into a footer, the environment automatically adds “Sum” to it, and the report will print the total from the report.

    Example / exercise – simple report with one data item

    The following example shows how to use the basic sections in a table in a report with 1 data item.

    1)     Create a new report with one data item Customer. On Sections, add Customer No. Name and Balance (LCY):


    Unless you plan to run this report from the classic client it doesn’t matter where or how you add fields to the sections, or if you add header / footer  or any other types of sections. You only add fields to the section because then they will then become part of the data source in VS report designer.

    2)     Click on View -> Layout to open VS report designer. Add a table from the toolbox. Look at “Website Data Sources” to see the fields available in the data set. This is the fields that you put on the sections. So if you want to add fields here, then go back to the sections, add them there, and next time you open the layout those fields will be there.

    3)     Drag and drop Caption fields into the Header, Normal fields into the Detail, and Balance_LCY_ into one of the Footer-cells:


    That’s all you have to do to create a simple report. So now let’s add some more structure to the report.

    Multiple data items:
    This is where it can easily go wrong if you forget a step or two. First, we need to go back to the “old” environment and see how this affects your data structure.
    The data structure and links are decided by the data items on the report and the fields you put on the sections (View -> Sections). About adding fields to sections, there are two things to be aware of:
    1)    To include something in the data set, it must be on the sections
    2)    If you add sections for another data item, then this affects the data set and the way the report runs
    If you created the report from Example 1 above, then add the following:
    Add a new data item “Cust. Ledger Entry”. Indent and link it to the Customer data item as you would normally. If you now run the report, it will run just as before. Then go to sections and add one or more fields from “Cust. Ledger Entry”. Run the report again, and this time you will see a difference. When you added fields to the sections, you also expanded the data set. The table in the layout will now print a row for each record, and because you have added data to the data set, it will print one row for each. You need to group this data in order for it to make sense. This is where it can get a bit tricky.


    The table in VS report designer will just print all the data in the data set. Unless you group the data correctly, the result will not make any sense. To insert a group, highlight a row in your table, right click it, then “Insert Group”:



    For a group you must specify the Expression, which tells the table what to group by. When creating a group it’s for the indented table – in this case “Cust. Ledger Entry”. So we want to group it by Customer No. From the Customer table. So select that as the expression:



    Also, just to simplify the report, un-tick “include group footer”.
    This completes the structure of the table. But the report will print one group header and group fields, so leaving these empty will mean a lot of blank lines. To complete this report, drag fields into both the new group header and into details.

    This is where the report can easily get wrong if you miss a small detail, and where it may be necessary to try a few times before the report looks the way it should. The result of the report is a combination of data items, sections, and the table you created in VS report designer. So if something is not right, the problem may be any where in those areas. One tip: If the report prints a lot of blank lines, then check if you have any blank rows in the table. Here is a simple table layout that prints customer s and Cust. Ledger Entries:




    Table elements

    As described in the previous sections, you have to use the right table elements in the right places. This is what the icons of the table elements mean, and how and where to use them:

    TableHeader   Table header
    Will print once at the top of the table.

    GroupHeader   Group header
    This is for when you have an indented data item. The header will show data from the top-level data item, for example Customer No.

    TableDetail   Table Detail
    This corresponds to a body-section, either from a main table or from an indented table.

    GroupFooter    Group Footer
    This is also for indented data items. How this will print, depends on how you have set up the group in the table.

    TableFooter   Table Footer
    Will print once, at the end of the table



    Lars Lohndorf-Larsen (Lohndorf)

    Microsoft Dynamics UK

    Microsoft Customer Service and Support (CSS) EMEA

  • Microsoft Dynamics NAV Team Blog

    NAV 2009 - Report Designer - Introduction to the new environment


    Microsoft Dynamics NAV has always had its own report designer. In NAV 2009 it still does, but in addition to this you can also use the Visual Studio (VS) report designer.

    NAV 2009 – both the classic and the new client – will still run reports designed in NAV’s report designer. So in way nothing has changed. You can still use the existing report designer. VS report designer offers a lot of new options and features. The idea of this post is to describe what features out of 100s that you actually need. When it comes to a simple report, only a very few features are needed to get started. This post tells you which ones they are.


    Old versus New

    The classic client can still only run reports designed in the classic report designer. The new client (Role Tailored client – RTC) can run reports designed with either the classic or with VS report designer. When RTC launches a report, it checks if a layout has been defined in VS Report designer. If it has, then it will run that. If no layout has been defined, it will launch the report engine from the classic client and run the report exactly like it would have been run from a classic client. This does require that a classic client has been installed as well, even if the user will never have to run this client.
    I this way you can use the classic report designer for some reports, and VS Report designer for others.
    Report design is still done from Object Designer in the classic client.

    VS report designer is a different environment. It has features that are not available in the classic report designer, but also limitations compared to the classic report designer. For example, it does not support Trans-Headers and Footers. But as described above, the VS report designer is a choice you have – you can still use the classic report designer if there are things you can't achieve with the VS report designer.

    The new environment

    Sections is where you make your report layout in the classic report designer. This will run in the classic client as well as in RTC. For RTC you can create a report layout, which is done in VS report designer. So “Sections” refer to the classic report layout while “Layout” refers to the layout done in VS.

    The classic report designer introduces four new options:

    Tools -> Create Layout Suggestion:

    This makes a “best effort” to transform your classic report design and create a suggested layout in VS report designer. This can do a lot of the hard work for you so you don’t have to start from scratch, or design sections first in the classic report designer, and then create the layout in VS report designer. The tool can’t guarantee to transform every report, but it will always at least give you a good start, and for many reports it will do all the work needed.

    Tools -> Delete Layout:

    This deletes the report layout

    View -> Layout:

    This opens VS report designer and is where you will go to design your report for the RTC.

    View -> Request Page:

    The classic client runs forms while the new client runs pages. The same goes for request forms on a report. So if you want to add options to the report for the new client, then do that in the request page.


    VS Report Designer

    Going to View -> Layout opens VS Report Designer which looks like this:


    The parts of this environment you need, are:


    Normally you can switch between the Toolbox and “Website Data Source” (fields) as shown in the red circle in the picture above. But if for some reason the toolbox is not visible, then go to View -> Toolbox. If you use the “Create Layout Suggestion”, then this will add the necessary elements to the report, and you won’t need the toolbox. If you create a layout from scratch, then all you need from the toolbox – at least for simple reports , is a table:



    Website Data Source:

    This is where you select the fields to print on the report. It will automatically show you anything that you have added to sections in the classic report designer. So to add / remove fields from here, go to sections and add / remove them from there.
    To add the fields from the WebsiteData Source, just drag and drop them into a table or to where you want them displayed.

    VS report designer has 100s more options, features and elements, but the ones mentioned here are the only ones you need to get started.

    Workflow – designing reports

    So having explained which features you need - at least to create a simple report - this is how to use them:

    When you have done your layout in VS report designer, close and save it which will bring you back to the classic report designer. Moving one line up or down will prompt you if you want to load the report layout. When you do that, the VS report layout is saved in the report object itself.
    So exporting a report from Object Designer will export all of it, including the layout you have designed in VS report designer, whether you export the object as .txt, .xml or .fob. If you export the report as .txt or .xml, you can see the VS report layout added at the bottom of the report, in a section called RDLDATA.

    Finally, to run the report, either run it directly from Start -> Run, like this to run report 99800:
    or of course you can add the report to a page to run it from the new client.


    Lars Lohndorf-Larsen (Lohndorf )

    Microsoft Dynamics UK

  • Microsoft Dynamics NAV Team Blog

    TAP Customers and Partners Deploy Microsoft Dynamics NAV 2009


    Most Microsoft product teams involve their top customers and partners the development process via Technology Adoption Programs (TAP).  These high touch engagements result in much better product quality and features as well as early (pre-RTM) deployments of new versions. 

    The Dynamics NAV 2009 TAP has succeeded with 10 live customers in Germany, Denmark, Canada and the US already deployed and using NAV 2009 CTP4!  Six of these are using upgraded ISV solutions for distribution, manufacturing, furniture and project management.  We also have previous Epicor and Infor customers who have made the switch to NAV 2009 as part of the TAP.  All deployments are using the new Role-tailored Client and several are running multiple NAV servers.

    The TAP has also made significant quality improvements to NAV 2009 with over 100 fixed bugs and several major design changes.  These great accomplishments are the result of over a year’s hard work between the TAP partners, NAV core teams and the TAP PM Team (including my European counterpart, Kipper York).  We are already receiving excellent feedback from the Go-Live customers, especially concerning the new client.

    For those of you attending Convergence 2008 in Copenhagen on November 18-20, we encourage you to attend the “Meet the Early Adopters” Sessions:
    •    TAP Partners: 11/19/2008 1:30PM-2:30PM, room B4.2
    •    TAP Customers: 11/20/2008 9:00AM-10:00AM, room B4.3

    We'll have lots of other NAV 2009 content at Convergence.  Hope to see you there and to share the excitement!

    - Brett Johnson

  • Microsoft Dynamics NAV Team Blog

    Dynamics NAV 5.0 SP1 and export to Excel


    A number of issues previously reported when running with Dynamics NAV 5.0 and using send-to Excel functionality, are now corrected.  These issues include (among others): decimals exported as text, Item/Customer numbers exported as decimals, dates exported as decimals.

    To implement correction, update with 5.0 SP1, update 1 (KB 956161, build 27191), use default style sheets included in SP1, and make the following change to default style sheet NavisionExportToExcel.xslt:

    Open the style sheet file in notepad, default file is NavisionFormToExcel, placed in Stylesheet folder of the Client folder.

    Browse to the following line :   


    xsl:when test="@subtype != 'number'">

    and replace the line with


    xsl:when test="@datatype != 'Decimal'">


    Then locate the following line :   


    xsl:when test="@subtype = 'number'">

    and replace the line with


    xsl:when test="@datatype = 'Decimal'">


    Jasminka Vukovic (jvukovic)

    Microsoft Dynamics NO

    Microsoft Customer Service and Support (CSS) EMEA

  • Microsoft Dynamics NAV Team Blog

    Basic SQL - Restoring a SQL Server backup


    This post is part of "Overview of NAV-specific SQL features for application consultants".

    You can back up your Microsoft Dynamics NAV database either from a NAV client or from SQL Server Management Studio. To restore a backup made from SQL Server, follow these steps:

    1)     Open SQL Server Management Studio
    2)    You don’t need to create a database first, like you do from NAV. Just right click on Databases, then select “Restore Database...”.
    3)    In the box that opens, type in a name for your new database. You can name it anything. Then change the source from “From database” to “From device”. Device, in this case, just means file.
    4)    Click the Assist Edit button next to “From Device”, which opens a new dialogue box. Click Add, and then select the SQL backup you are restoring, and click OK.
    5)    SQL Server will list a few details about the backup you selected. Tick the “Restore” box, and then click OK:


    The new database should now appear in SQL Server management studio, and you can access it from a NAV client.


    Lars Lohndorf-Larsen (Lohndorf)

    Microsoft Dynamics UK

    Microsoft Customer Service and Support (CSS) EMEA

Page 42 of 50 (745 items) «4041424344»