Microsoft Dynamics NAV

Team Blog

  • Microsoft Dynamics NAV Team Blog

    Cumulative Update 3 for Microsoft Dynamics NAV 2015 has been released

    • 8 Comments

    Cumulative Update 3 includes all application and platform hotfixes and regulatory features that have been released for Microsoft Dynamics NAV 2015. 

     The cumulative update includes hotfixes that apply to all countries and hotfixes specific to the following local versions:

    •   AU - Australia
    •   AT - Austria
    •   BE - Belgium
    •   CH – Switzerland
    •   CZ – Czech Republic
    •   DE - Germany
    •   DK - Denmark
    •   ES - Spain
    •   FI  - Finland
    •   FR - France
    •   IS - Iceland
    •   IT - Italy
    •   NA - North America
    •   NL - Netherlands
    •   NO - Norway
    •   NZ - New Zealand
    •   RU – Russia
    •   SE - Sweden
    •   UK - United Kingdom

    Where to find Cumulative Update 3

    You can download the cumulative update from KB 3024901  – Cumulative Update 3 for Microsoft Dynamics NAV 2015 (Build 39368). 

    Additional Information

    For information about how to install the cumulative update, see How to Install a Microsoft Dynamics NAV 2015 Cumulative Update

    For information about how to work around a recent process change, see How to Get Back the 'Hotfix Directories' from NAV 2015 Cumulative Update 1.

    For a list of all cumulative updates for this version, see Released Cumulative Updates for Microsoft Dynamics NAV 2015.  

  • Microsoft Dynamics NAV Team Blog

    Using SQL Server Extended Events to produce a Blocked Process Report

    • 1 Comments

    Blocking in SQL Server is a mixed blessing! It is a SQL Server’s way of ensuring data integrity which is a basic requirement for any database management system but when users encounter a lot of blocking it makes the application appear slow and sometimes unusable. Therefore, system administrators need to be able to analyse SQL Server blocking and take action to minimise it in order to get the best database performance possible.

    A traditional approach to blocking analysis is to use Windows Performance Monitor. The “SQL Server:Locks” counters gives you a graphical view of lock activity, e.g:

    • How many locks are being requested per second
    • How long SQL queries are waiting due to blocking.
    • How many locks requests are timing out.

    You can then use SQL Server Agent to configure alerts on these performance counters and be notified, for example, when lock wait times exceed whatever threshold you deem acceptable.

    Troubleshooting blocking using Performance Monitor (or SQL Server Profiler) is all very well but can impose a performance hit which may not be practical for a busy, resource intensive live environment. Also, it may not provide all of the details you need to understand the cause of the blocking. If only there was a lightweight way of monitoring SQL Server blocking problems which would be suitable for a busy live environment!

    You might be surprised to find out that just such a lightweight monitoring mechanism has existed since SQL Server 2008 was released. Ladies and gentlemen, allow me to introduce my good friend, the “Extended Events” feature of SQL Server! Several key performance indicators can be monitored using SQL Server Extended Events. The following steps show in detail how you can create a “Blocked Process Report” for your SQL Server environment to capture relevant blocking details without incurring much of a performance penalty.

    First, you need to decide how many seconds a process should be blocked for in order for it to be included in the report, i.e. the blocked process threshold. If you set this value too low you may generate too much noise in the report. If you set it too high you might not get any processes waiting long enough to appear in the report. For Microsoft Dynamics NAV environments, the value should be less than any “Lock Timeout” setting which may be enabled (as set in the NAV Development Environment, see File -> Database -> “Alter Database” -> “Advanced” tab). For this exercise I will only include processes which are blocked for more than 5 seconds in my Blocked Process Report.

    So, I need to run some TSQL statements in order to configure 5 seconds as the blocked process threshold. The following will do the trick:

    exec sp_configure 'show advanced options',1;
    go
    reconfigure
    go
    exec sp_configure 'blocked process threshold',5;
    go
    reconfigure
    go

    NB: After running the above, you may want to consider setting the ‘show advanced options’ value back to ‘0’ if your SQL Server administrator prefers this.

    Now, to create and test the Blocked Process Report. The following are the steps required (examples are based on SQL Server 2012 SP1):

    1. Start SQL Server Management Studio (SSMS) and open the “Extended Events” folder as shown below:

    clip_image001

    2. Right click on the “Sessions” folder and select “New Session Wizard”. Click “Next” on the Introduction page.

    3. When prompted, provide a “Session Name”, e.g. My Blocked Process report.

    4. For the “Choose Template” page select “Do not use template”

    5. In the “Select Events To Capture” enter the word “blocked” in the “Event Library” text box. This will limit the events listed so you can easily identify the “blocked_process_report”. Select this report and then click on the ‘>’ button in order to move this into the “Selected events” pane. Then click “Next”.

    6. In the “Capture Global Fields” page, click on the “Finish” button.

    7. On the “Success” page, click on the “Close” button.

    8. At this stage you have created a Blocked Process Report and should be able to see it shown as an “Extended Report” Session, like this:

    clip_image002

    9. For our requirements, we want to store the report session data into a file as this will be more convenient to work with, especially if you want to send it to a Microsoft Support Engineer! To do this, right click on the “My Blocked Process Report” and select “Properties”.

    10. In the left pane of the “Session Properties” widow select the “Data Storage” page (see screenshot in the step below:

    11. Click on the “Add” button to add a new storage type. In the “Type” column select “event_file” as shown here:

    clip_image003

    12. Now fill out the “Properties” to specify a where you want the report file to be placed and what space values you want to allow. Then click “OK”

    Of course, there are many other options you can configure and additional information you can capture but for this exercise we will just create a simple report in order to try out the feature. You can right-click on the “My Blocked Process” report and change other properties later if you like.

    So, let’s start our report session and then cause some blocking so you can see how the report looks. The following steps can achieve this:

    1. To start the session simply right click on “My Blocked Process Report” and select “Start Session”.

    2. To create some blocking, first run the following TSQL commands in a SSMS Query window:

    use tempdb
    go
    create table Table1 (a1 int)
    go
    begin tran
    insert into Table1 values(1)
    go

    3. Now start a 2nd TSQL Query Window and run the following command which will be blocked behind the connection running the above statements:

    use tempdb
    go
    select * from table1

    4. Leave the 2nd TSQL Query Windows running in a blocked state for a few moments so that the blocking report can start to accumulate blocking events. After about a minute, enter the following TSQL statement in the 1st SSMS Query Window to remove the cause of this blocking incident:

    rollback tran

    5. Now right-click on the “My Blocked Process Report” in SSMS and select “Stop Session”.

    6. To review the details in the blocked process report go to the file location you specified for the “event-file” you stipulated earlier (see step 11 above). In the folder you specified you should see a file with a name like this:

    “My Blocked Process Report_0_130651143384850000.xel”

    7. Double click on this report and it will open it in SSMS. It should contains some events related to the blocking we created above and will look like this:

    clip_image004

    8. As you can see, there are multiple events recorded. This is because we had a single blocked process which was waiting for over 5 seconds (but it was blocked for a minute so it was reported multiple times). Double-click on the first of these events and you will see some more detail about the blocking incident, like this:

    clip_image005

    9. At first glance, the fields shown above may appear only mildly interesting. The duration value is in microseconds so the above event records a blocking process which had been in a blocked state for just over 5 seconds. You can see that the block occurred in the tempdb database along with some other details. You could be forgiven for being underwhelmed by the information displayed here but before giving up take a closer look at the “blocked_process” field which contains some xml content. This is the good stuff we are looking for. Double-click on the xml value in this field to open it up in SSMS. You will see something like the following:

    image

    10. This information can be extremely useful for understanding the blocking problem. Notice that it contains the following details (and more):

    For the Blocked Process:

    • Object ID
    • Wait time (in milliseconds this time)
    • When the transaction started
    • Lock Mode
    • Transaction status (e.g. suspended)
    • Connection ID (SPID)
    • Client application name
    • Machine name (Hostname)
    • Login name
    • Isolation level
    • Input buffer, i.e. the actual SQL statement which was blocked.

    For the Blocking process:

    • Object ID
    • Wait time
    • Connection ID
    • Input buffer, i.e. the SQL statement which caused the blocking. Please note that this only appears on the first event record for each distinct blocking incident.

    Hopefully you will find this approach to diagnosing blocking problems helpful. As you may have noticed, Extended Event Sessions can be used to collect all sorts of other system information from SQL Server but in this blog we have only been concerned with blocking analysis. The fact that these Extended Event Sessions are fully integrated with the SQL Server engine means that they have very little impact on performance making this approach ideal for monitoring live environments.

    Gerard Conroy
    Dynamics NAV Support EMEA

    P.S: Have you ever wondered “How do I Profile Application Code in Microsoft Dynamics NAV 2013 R2”? If so, you need look no further: http://msdn.microsoft.com/en-US/dynamics/nav/dn858631

  • Microsoft Dynamics NAV Team Blog

    C/AL Coding Guidelines used at Microsoft Development Center Copenhagen

    • 4 Comments

    Recently, the NAV Design Patterns team published the C/AL Coding Guidelines that we use at Microsoft Development Center Copenhagen to the Dynamics NAV Community Wiki site. Please join us there if you want to read and discuss the guidelines. 

    However, we've been asked for a printable version of the guidelines as well, so we attached a PDF file with the current version to this blog post. This PDF file will not be updated if and when the guidelines change, so please consider them a snapshot as of January 2015. For more information, see the Dynamics NAV Community Wiki.

     

    Best regards,

    The NAV Design Patterns team

  • Microsoft Dynamics NAV Team Blog

    NAV Design Pattern - the Released Entity Pattern

    • 0 Comments

    Happy New Year, everyone!

    With the new year, here's a new pattern to warm us up. Coming from a Danish partner, this pattern describes how to handle data entities when they need to be in a consistent or in a certain state before further processing can be allowed. Thank you Henrik Langbak and Kim Ginnerup from Bording Data for sharing this knowledge with the NAV developers community.

    Best regards,

    The NAV Patterns team

    Meet the Pattern

    This pattern prevent data from being used elsewhere before it is in a system consistent state.
    Microsoft Dynamics NAV inserts a record as soon as the primary key has been set. But the record may not be in a valid state at this point in time. How do you know if a newly inserted record is ready for use?

    Know the Pattern

    Whenever you need to stall the release of data, you can use this pattern.

    Because Microsoft Dynamics NAV decides when a record is written to the database, it may not be in a system consistent state. Nobody should use the record before everything is in place and the record is valid. An inserted record may even have data in other tables that needs to be inserted and in a valid state before other parts of the system can use the data without running into a problem.

    Data entered into the system may have to be approved by a second person before it can be used.

    Data requires different parties (e.g. Departments) to add information before data is valid.

    The solution is an Option Field with two or three values:
    (Open, Released) or (Open, Pending, Released)

    The states should be interpreted as:

    State

    Description

    Open

    Not all data is in place. The record is system inconsistent. The record or record hierarchy is invisible for all other parts of the system.

    Pending

    The record is system consistent. But is awaiting someone to manually raise the state to Released.
    The record is still invisible.

    Released

    All data is in place and the record is system consistent, and ready for use. It is now visible for the rest of the system. The state can never be reversed.

    The option field name: Release State.

    This pattern is very similar to the Blocked Entity pattern, but it has one significant difference.
    The record is not visible to any part of the system, before it is in the Released state.
    There is no going back. When the Released state is reached, it will stay that way for the life of the record. In case of a tri-state, it is ok to bypass Pending seen from a system state perspective.

    If there is a hierarchy, e.g. Header and Lines, then the Release State field resides on the Header. As long as the Header remains unreleased, the lines are considered inconsistent and must not be used.

    The important and critical part of this pattern is that the whole application needs to obey the “Release State”-contract or the system will fail. 

    Use the Pattern

    To use this pattern you need to create an Option Field named: “Release State” with at least the two states: Open, Released. 

    Read more about this pattern on the NAV Design Patterns Wiki community page...

  • Microsoft Dynamics NAV Team Blog

    Code Upgrade: Merging Version Lists

    • 2 Comments

    Merging cumulative updates into your own Microsoft Dynamics NAV solutions has become a lot easier with the new merge utilities. They are based on the concept of three-way merge to reconcile two sets of changes made (independently) to a given base version. For example, when applying Microsoft Dynamics NAV 2015 Cumulative Update 1 to a customized database, the customized database and the cumulative update are both derived from Microsoft Dynamics NAV 2015 RTM, which is the shared based version in that case.

    There is one aspect, though, that raised quite a few questions from the community and that is merging of the Version List object property.  Out-of-the-box the merge command offers only very limited support to handle this. You can either choose to clear the version list or take the version list from the modified or target object. Since the Version List is just text, we couldn't really assume how it is used generically and provide corresponding merge capabilities. However, the Merge-NAVApplicationObject Windows PowerShell cmdlet provides very rich output, and in combination with the command for setting object properties it is possible to deal with version lists any way you like.

    What appears in the PowerShell console when the Merge-ApplicationObject cmdlet completes is just a summary. The cmdlet actually returns a collection of objects that each contain information about a merge. To inspect what information is available, you can assign the result to a variable and use the Get-Member comman, as shown in the following code snippet:

    $m = Merge-NAVApplicationObject ...

    $m | Get-Member -MemberType Properties

     

       TypeName: Microsoft.Dynamics.Nav.Model.Tools.MergeInfo

     

    Name        MemberType   Definition

    ----        ----------   ----------

    PSPath      NoteProperty System.String PSPath=

    Conflict    Property     Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Conflict {get;}

    Error       Property     Microsoft.Dynamics.Nav.Model.Tools.ErrorInfo Error {get;}

    Id          Property     int Id {get;}

    MergeResult Property     Microsoft.Dynamics.Nav.Model.Tools.MergeResult MergeResult {get;}

    Modified    Property     Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Modified {get;}

    ObjectType  Property     string ObjectType {get;}

    Original    Property     Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Original {get;}

    Result      Property     Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Result {get;}

    Target      Property     Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Target {get;}

     

    The output of the merge is a collection of MergeInfo objects. Each MergeInfo object represents a merge operation for an application object and contains information about the original, modified, target and result objects. As such, the MergeInfo objects give us access to the original, modified, and target version list, such as:

    $minfo = $m | select -first 1

    $minfo.Modified.VersionList

    Assuming that given the three input version lists we can determine the desired version list for the merge result, we can define a function that takes such a MergeInfo object to calculate the resulting version list:

    function New-NAVVersionList($MergeInfo)

    {

    ...

    }

     

    Before we implement this function, let's first see how we could use it. The Set-NAVApplicationObjectProperty cmdlet updates the object properties (including the version list) for all application objects in a text file:

    Set-NAVApplicationObjectProperty -TargetPath objects.txt -VersionListProperty 'v1'

    When we iterate over all MergeInfo objects, we can use this command together with the New-NAVVersionList function to update the version list for each object in the merge result:

    foreach($mInfo in $m)

    {

      $versionList = New-NAVVersionList $mInfo

      Set-NavApplicationObjectProperty -TargetPath $mInfo.Result -VersionListProperty $versionList

    }

    What remains is the implementation of the function that actually calculates the new version list based on the version list of the three inputs (original, modified, and target). For instance, to simply concatenate modified to target:

    function New-NAVVersionList($MergeInfo)

    {

      # MyCustomVersion,TheirModifiedVersion

      "$($MergeInfo.Target.VersionList),$($MergeInfo.Modified.VersionList)"

    }

    How version lists are often used is that for each add-on or customization for which an application object is changed a version tag is added (separated by comma). In turn, each version tag typically consists of some product code and a version number. For example a Microsoft Dynamics NAV 2015 W1 object that was customized for my add-on (MY) and their add-on (THEIR) could get version list: NAVW18.00.00,MY1.1,THEIR6.2. Note that the version number for the NAV version tag is composed of a major, minor, and build number. The build number is typically updated in the case of cumulative updates.

    When merging an update into your code any version tag might be updated or new version tags might be added. The result of merging version lists should contain one tag for each product code that occurs in the modified and target version lists and it should be the tags with the highest version number for that product code. With these requirements our New-NAVVersionList function becomes this:

    function New-NavVersionList($MergeInfo, [string[]]$ProductCode = 'NAVW1')

    {

        $allVersions = @() + $MergeInfo.modified.versionlist -split ','

        $allVersions += $mergeInfo.target.versionlist -split ','

     

        $mergedVersions = @()

        foreach ($code in $ProductCode)

        {

            # keep the "highest" version tag for $code

            $mergedVersions += $allVersions | where { $_ -like "$code*" } | sort | select -last 1

     

            # remove all $code version tags

            $allVersions = $allVersions | where { $_ -notlike "$code*" }

        }

     

        # return a ,-delimited string consisting of the "highest" versions for each $ProductCode and any other tags

        $mergedVersions += $allVersions

        $mergedVersions -join ','

     

    This function was brought to you by Bas Graaf.

    On behalf of him and the rest of the Dynamics NAV team, your blog editor wishes you all Happy Holidays!

  • Microsoft Dynamics NAV Team Blog

    Welcome to Dynamics NAV App Update Version 1.1

    • 5 Comments

    An update to Microsoft Dynamics NAV for tablets is now available. Update to version 1.1. from your preferred store; Windows Store, or Google play. The update to version 1.1 will soon be available on the App Store as well.

    Note that the minimum requirement for installing the Dynamics NAV for tablets update is that Microsoft Dynamics NAV 2015 CU1 is installed, if you use Microsoft Azure Active Directory (Azure AD) as the authentication mechanism. For more information, please see our earlier blog post Important Note Regarding the Soon-To-Be-Released Dynamics NAV App Update Version 1.1.

    The changes and fixes in this version are:

    • Fixed security vulnerability on Android.
    • Support for iOS 8.x
    • When starting the app, the Service name field contains a hint to the expected format of the URL.
    • Avoid connection issues on some active directory domains.
    • Adjusting the service URL is easier, because the Service name already contains the value entered the first time.
    • Added language support for Dynamics NAV for Android. The list now includes: Danish (Denmark), Dutch (Belgium), Dutch (Netherlands), English (Australia), English (Canada), English (India), English (New Zealand), English (United Kingdom), English (United States), Finnish (Finland), French (Belgium), French (Canada), French (France), French (Switzerland), German (Austria), German (Germany), German (Switzerland), Icelandic (Iceland), Italian (Italy), Italian (Switzerland), Norwegian (Bokmål) (Norway), Russian (Russia), Spanish (Mexico), Spanish (Spain), and Swedish (Sweden).
    • Added language support for Dynamics NAV for iPad. The list now includes: Danish (Denmark), Dutch (Belgium), Dutch (Netherlands), English (Australia), English (Canada), English (India), English (New Zealand), English (United Kingdom), English (United States), Finnish (Finland), French (Belgium), French (Canada), French (France), French (Switzerland), German (Austria), German (Germany), German (Switzerland), Icelandic (Iceland), Italian (Italy), Italian (Switzerland), Norwegian (Bokmål) (Norway), Russian (Russia), Spanish (Mexico), Spanish (Spain), and Swedish (Sweden).

    Additionally, Dynamics NAV for tablets will include the following changes if your administrator has deployed Microsoft Dynamics NAV 2015 Cumulative Update 2:

    • Getting a "The tenant 'myTenant' was not found." error message when you try to connect to a server configured with Azure AD authentication and hostname-based tenant resolution.
    • Getting a "The tenant 'myTenant' was not found." error message when you try to connect to a server configured with Azure AD authentication and the tenant was specified as a URL parameter.
    • Microsoft Dynamics NAV for tables can now connect to a server on localhost using HTTP. This is intended for one-box demo deployments such as demoing on Surface Pro 3.

    For more information on Microsoft Dynamics NAV 2015 Cumulative Update 2, see http://go.microsoft.com/fwlink/?LinkId=522094 (login to PartnerSource is needed).

  • Microsoft Dynamics NAV Team Blog

    Understanding Error Code 85132273 in Connection with GETLASTERRORCODE Statements

    • 5 Comments

    We recently received a few interesting requests about an error code appearing under particular circumstances: 85132273. This error might typically arise with the Windows Client but also with Web Services and NAS Services as well.

    Digging under the hood, this error message is related to a Primary Key violation in SQL Server tables.

    In most of cases, this could be due to C/AL code such as the following:

    IF NOT MyTable.INSERT THEN …

    This is quite an easy and diffuse syntax that looks innocent and clean (admittedly, we even have a few instances of it in the CRONUS demonstration database). However, it is a problematic use of code because it forces an INSERT into a table and if the record already exists, an implicit error is thrown. That gives us that violation of the primary key.

    From a development perspective, we recommend that you refactor the code, where possible, in the following way (under a LOCKTABLE):

    IF NOT MyTable.GET THEN MyTable.INSERT …

    This code is preferable for at least two reasons:

    1. More logically correct

      It does not throw an implicit error caused by a primary key violation. Therefore developers could use GETLASTERRORCODE statement family in a more logical way. This statement family may catch, then, the violation of the primary key server side even though no visible runtime error would ever be show to the user. As short example, this code:

      CLEARLASTERROR;

      SalesPost.RUN;

      MESSAGE(GETLASTERRORTEXT);

      might display the error code 85132273 if there are nested statements like IF NOT INSERT THEN in the SalesPost codeunit.

      Please, be aware that this type of trapped error will not be displayed if also codeunit.RUN has a C/AL exception handling such as:

      CLEARLASTERROR;

      IF NOT SalesPost.RUN THEN

        MESSAGE(GETLASTERRORTEXT);

      In this case, any nested trapped error that might arise from IF NOT INSERT THEN will not be intercepted and no error text will be shown for this kind of violation of primary key.

    2. More efficient in some cases.

      INSERT statements with an implicit violation of the primary key are costly and if the code is typically something like IF NOT INSERT THEN MODIFY and the number of MODIFY statements is high, the statement with IF NOT GET THEN INSERT ELSE MODIFY or, better, IF GET THEN MODIFY ELSE INSERT would be typically faster in terms of performance.

    If you intend to implement error statement like GETLASTERRORMESSAGE, GETLASTERRORCODE and GETLASTERRORCALLSTACK, then you might notice that C/SIDE error code refers to a DB:RecordExists. Attached to this blog post, you will find a simple page object as proof of concept to demonstrate when and how this error might arise for a better understanding.

    Please use the attached page object only for testing and understanding, and do not use it on a live environment. It is just to demonstrate the error code in a standard CRONUS demonstration database.

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

     

    Duilio Tacconi                                      Microsoft Dynamics Italy         

    Microsoft Customer Service and Support (CSS) EMEA

    Special thanks to Peter Elmqvist from nabsolution.se 

  • Microsoft Dynamics NAV Team Blog

    Cumulative Update 21 for Microsoft Dynamics NAV 2013 has been released

    • 0 Comments

    Cumulative Update 21 includes all application and platform hotfixes and regulatory features that have been released for Microsoft Dynamics NAV 2013.

    The cumulative update includes hotfixes that apply to all countries and hotfixes specific to the following local versions: 

    • AU - Australia
    • AT - Austria
    • BE - Belgium
    • CH - Switzerland
    • DE - Germany
    • DK - Denmark
    • ES - Spain
    • FI - Finland
    • FR - France
    • IS - Iceland
    • IT - Italy
    • NA - North America
    • NL - Netherlands
    • NO - Norway
    • NZ - New Zealand
    • SE - Sweden
    • UK - United Kingdom

    Where to find Cumulative Update 21

    You can download the cumulative update from KB 3020883 - Cumulative Update 21 for Microsoft Dynamics NAV 2013 (Build 38800).

    Additional Information

    For a list of all cumulative updates for this version, see Released Cumulative Updates for Microsoft Dynamics NAV 2013

    For a list of all hotfixes included in cumulative updates for this version, see the following CustomerSource and PartnerSource pages:

    CustomerSource:

    PartnerSource:

  • Microsoft Dynamics NAV Team Blog

    Cumulative Update 14 for Microsoft Dynamics NAV 2013 R2 has been released

    • 2 Comments

    Cumulative Update 14 includes all application and platform hotfixes and regulatory features that have been released for Microsoft Dynamics NAV 2013 R2.

     The cumulative update includes hotfixes that apply to all countries and hotfixes specific to the following local versions:

    •   AU - Australia
    •   AT - Austria
    •   BE - Belgium
    •   CH – Switzerland
    •   CZ – Czech Republic
    •   DE - Germany
    •   DK - Denmark
    •   ES - Spain
    •   FI  - Finland
    •   FR - France
    •   IS - Iceland
    •   IT - Italy
    •   NA - North America
    •   NL - Netherlands
    •   NO - Norway
    •   NZ - New Zealand
    •   RU – Russia
    •   SE - Sweden
    •   UK - United Kingdom

    Where to find Cumulative Update 14

    You can download the cumulative update from KB 3020884  – Cumulative Update 14 for Microsoft Dynamics NAV 2013 R2 (Build 38801). 

    Additional Information

    For more information about cumulative updates for this version, see Announcement of update rollups for Microsoft Dynamics NAV 2013 R2.

    For a list of all cumulative updates for this version, see Released Cumulative Updates for Microsoft Dynamics NAV 2013 R2

    For a list of all hotfixes included in cumulative updates for this version, see the following CustomerSource and PartnerSource pages:

    CustomerSource:

    PartnerSource

  • Microsoft Dynamics NAV Team Blog

    Important Note Regarding the Soon-To-Be-Released Dynamics NAV App Update Version 1.1

    • 1 Comments

    An update to Microsoft Dynamics NAV for tablets will soon be available; however, here is an important note before you install that update.

    If you are using Microsoft Azure Active Directory (Azure AD) as the authentication mechanism, you must first update your Microsoft Dynamics NAV 2015 installation to CU1 or later. For information about CU1, see http://go.microsoft.com/fwlink/?LinkId=518121 (login to PartnerSource is needed).

    In the meantime, make sure that your device does not automatically pick up the new and updated Dynamics NAV app update version 1.1. You do that by disabling the auto update apps option on the device. On Windows devices, you launch the Windows Store, and then go to Charms, then Settings, and then App updates. Set the Automatically update my apps to No. Then, once you have run the CU1 update, you can re-enable the automatic update on your device(s).

    There is more information to come soon about the Dynamics NAV App update version 1.1. Stay tuned.

  • Microsoft Dynamics NAV Team Blog

    Introducing a build version check between NST and Windows and Web clients

    • 6 Comments

    Have you ever wonder what 'The client version does not match the server version. You can only connect to a server with a matching version.' error message really means? Since the error message shows the file (build) versions of the client and server it has been speculated that only clients and servers of the same build can connect, which is not the case. What really happens is that we have a communication interface between Microsoft Dynamics NAV Server and clients that has an internal version number which we change when this contract is broken (interface is changed so that it is not compatible anymore), and in that case the versions will not match and you will receive this error.

    So, people has asked us why we don't change this version every time we deliver a Cumulative Update. Well, there is really no reason, as this would force all the installation to be changed simultaneously and also would snatch the opportunity to just update one side of the installation (for instance the Microsoft Dynamics NAV Windows client) without interrupting the rest of the system. I would recommend people to indeed only run on the same build as there could be some fixes that are thought to be on the Windows client, which are actually fixed on the server side (so there would be the impression that the issue is still present when only updating the client).

    We would like to help all installations types, and therefore we are introducing a new setting from Cumulative Update 2 for Microsoft Dynamics NAV 2015 & Cumulative Update 14 for Microsoft Dynamics NAV 2013 R2 which would allow you to decide what will happen when the file (build) version does not match. This does not mean that we have gotten rid of the interface version, which give us now 5 different possibilities, which I will elaborate on later on.

    I must start by clarifying that because we actually needed to change the interface we will get an error (client version does not match the server version) when combining builds from CU 2/CU 14 to pre CU 2/CU 14.

    The new Server setting is called ClientBuildRestriction, and it has three possible values: AlwaysConnect, WarnClient and DoNotAllow (the default setting is WarnClient). The behavior being:

    • AlwaysConnect - This will work exactly as it has been working until now. If the interface is compatible we will allow the client to connect regardless if the build versions match between them or not.
    • WarnClient (default) - If the build versions match between server & client, connect as always (implicit that the interface is the same), else, show a warning (The build version of your Microsoft Dynamics NAV client or the Microsoft Dynamics NAV web server components is different from the build version of the Microsoft Dynamics NAV Server instance that you connect to. However, your connection works.) and connect as before.
    • DoNotAllow - If the build versions match between server & client (implicit that the interface is the same), connect as always, else, refuse the connection (the error is the same as when the interface does not match).

    So, what are the 5 different possibilities I have referred to before?

    • Build versions are the same (Microsoft Dynamics NAV Server and client) - Connect without any error or warning regardless of the new setting (if present) on the server.
    • Build version are different because we have a pre CU 2/CU 14 and a CU 2/CU 14 or above - Error (as before) regardless of the new setting (if present) on the server (due to the interface version being different).
    • (3 variants) Build version are different because we have a CU 2/CU 14 and a post CU 2/CU 14, then we need to refer to the 3 server settings as described before.

    If you reflect about what I have just written, this new setting will not help at all until we release another post CU 2/CU 14 release that you can combine "useful" builds with.

    We hope that this new server setting will help you manage better your installations.

    Best regards

    Jorge from the NAV team

  • Microsoft Dynamics NAV Team Blog

    Cumulative Update 2 for Microsoft Dynamics NAV 2015 has been released

    • 16 Comments

    Cumulative Update 2 includes all application and platform hotfixes and regulatory features that have been released for Microsoft Dynamics NAV 2015. 

     The cumulative update includes hotfixes that apply to all countries and hotfixes specific to the following local versions:

    •   AU - Australia
    •   AT - Austria
    •   BE - Belgium
    •   CH – Switzerland
    •   DE - Germany
    •   DK - Denmark
    •   ES - Spain
    •   FI  - Finland
    •   FR - France
    •   IS - Iceland
    •   IT - Italy
    •   NA - North America
    •   NL - Netherlands
    •   NO - Norway
    •   NZ - New Zealand
    •   RU – Russia
    •   SE - Sweden
    •   UK - United Kingdom

    Where to find Cumulative Update 2

    You can download the cumulative update from KB 3020885  – Cumulative Update 2 for Microsoft Dynamics NAV 2015 (Build 38798). 

    Additional Information

    For information about how to install the cumulative update, see How to Install a Microsoft Dynamics NAV 2015 Cumulative Update

    For information about how to work around a recent process change, see How to Get Back the 'Hotfix Directories' from NAV 2015 Cumulative Update 1.

    For a list of all cumulative updates for this version, see Released Cumulative Updates for Microsoft Dynamics NAV 2015.  

  • Microsoft Dynamics NAV Team Blog

    How to change the collation on a Microsoft Dynamics NAV 2013 R2 database.

    • 5 Comments

    Some significant changes have been introduced to the internal database structure for Microsoft Dynamics NAV 2013 R2 in order to support the powerful new Multitenancy functionality. These changes impact on how the NAV application manages a collation change whether or not you are using Multitenancy.

    At first glance, changing the NAV database collation seems to be the same old process as before. It can be achieved by following the steps below:

    1. Shut down the NAV middle tier service and (optionally) take a backup of the database.

    2. Open the Dynamics NAV Development environment

    3. Go to the “File” menu option and then “Database” -> “Alter”.

    4. In the “Options” tab, click on the “Single user” check box in order to change the database into single user mode. If you get the following message you need to remove other users from the database before proceeding:

    clip_image001

    5. Once the database is in single user mode, return to the “Alter Database” dialog box you were in earlier and select the “Collation” tab and modify the database collation as desired. This will take a few moments and a progress bar will indicate how the process is performing. You will soon see the following message to confirm the change:

    clip_image002

    6. As indicated in the above message, you need to return to the “Options” tab in the “Alter Database” dialog in order to uncheck the “Single User” check box.

    7. At this stage you can (optionally) take a backup of the database and then restart the NAV middle tier service.

    After following the above process you will have successfully changed the Dynamics NAV database collation – job done! The information below may be of interest if you want to understand what is happening behind the scenes as the collation change is applied in the SQL Server database but it is not required knowledge and no further manual steps are required in order to complete the collation change operation.

    There are some significant changes to the way the collation changes you have configured will be implemented at the SQL Server level compared with earlier versions of Dynamics NAV. If you use SQL Server Management Studio (SSMS) to check the NAV database collation (right click on the database and select “Properties”) you will see the old collation and not the one you have just applied via the NAV development environment. This can be confusing because earlier versions of NAV would update the collation on the database level. No more. With NAV 2013 R2 we alter the collation at the field level for all NAV tables. The Multitenancy design requires that we do *not* change the collation at the database level.

    If you check one of the character (nvarchar) fields in a NAV table in SSMS (e.g. right click on the field and select “Properties”), you may notice that the old collation is shown. This can be for several reasons. The most likely reason is because the collation change for that field has not been applied yet. With earlier versions of Dynamics NAV the collation changes were applied synchronously at the time you applied the change in the Dynamics NAV development environment and were therefore visible immediately at the SQL Server level. No more. With NAV 2013 R2 the changes are applied at the SQL database level asynchronously by the Dynamics NAV middle tier in a process referred to as “Schema Synchronization”. This process will normally run automatically in the background as soon as a Windows Client attempts to access the database. However, if you like you can force a Schema Synchronization manually at any time via Powershell. If you have this requirement then start the Dynamics NAV Administration Shell with Administrator rights and execute: Sync-NAVTenant <NAV Instance Name>

    Sometimes, even after schema synchronization has run successfully you might still notice that a field property in SSMS is showing the old collation. This can be due to the fact that the schema synchronization can take a few minutes to complete on a large database. If you check again later you will probably see the new collation has been applied. This delay does not affect users however because at the point a user touches a table the middle tier will apply any pending schema synchronization for that table immediately - just in time for the user to access the table. If you want to force the immediate schema synchronization for a specific table then go to the NAV development environment and “Run” the table from Object designer. This will open the table contents in a list page in the Windows client and thereby force the schema change for that specific table.

    Even after the schema synchronization has completed successfully and all schema updates are fully applied you might still notice that some fields are using the original collation. This may be due to the fact that Dynamics NAV will never alter the collation for fields which have been defined with the NAV data type set to dateformula.

    Gerard Conroy
    Dynamics NAV Support EMEA

  • Microsoft Dynamics NAV Team Blog

    NAV Design Pattern - Document Pattern

    • 3 Comments

    If you’re just starting with NAV, this pattern is a must-know for any NAV developer or consultant. Thanks to Xavier Garonnat from knk Ingénierie in France for documenting it.

    Best regards,

    The NAV Patterns team

    Meet the Pattern

    A document structure contains a header and a set of lines. Each line is linked to the header and could have common data with header.

    Know the Pattern

    This pattern should be used as a basis to build any document, showing a header and multiple lines in the same page.  Basically, a document is at least composed of two tables and three pages, as shown below:

    Use the Pattern

    You should use it any time you have to capture and store a document.

    Example 

    To build this example from scratch, you will need:

    • Two tables, one for the header (called “Document Header”), and one for the document lines (called “Document Line”). Each document will be composed of “1 to N” line(s).
    • Three pages, one for the header, one for the subpage (lines), and the last for the document list obviously.

    Table "Document Header": Is the "header" table of your document (like Sales Header, Purchase Header, Transfer Header …)  

    • Add a field "No." (Code 20): Should be the first field and primary key of your documents, to be driven by Serial No. (See corresponding design pattern)

    For this sample, I just added a “Sell-to Customer No.” to this table. Don’t forget to manage deletion of lines with trigger OnDelete().

    Table "Document Line": will store the lines of the document 

    • Add a field "Document No." (Code 20): Should be the first field and is related to table "Document Header": set TableRelation to your "Document Header" table
    • Add a field "Line No." (Integer): this field will be populated automatically by the subpage page (see AutoSplitKey)

    First (Primary) Key must be “Document No.,Line No.". On table properties, set PasteIsValid to No (to avoid copying/pasting lines, will be implemented by “Copy document”, another pattern).

    For my sample, I just add a couple of fields: “Item No.” and “Quantity” to this table (just copy/paste standard fields from “Sales Line” table and delete trigger code, this will insure that each field will be well designed)

    Page "Document Subpage”: will display the lines in the main form, and will be in charge of assigning line number automatically.

    Create the page for table “Document Line” with the wizard by selecting the ListPart template, add all yours fields except the primary key (“Document No.” and “Line No.”).

    Then edit the properties: 

    • Set AutoSplitKey, DelayedInsert and MultipleNewLines to Yes: this combination will make your subpage work as required. 
    • AutoSplitKey is used to set NAV calculate the last field of the key (“Line No.”) with proper numbers (10000, 20000…).

    Read more about this pattern on NAV Design Patterns Wiki community page...

  • Microsoft Dynamics NAV Team Blog

    How to Compile a Database Twice as Fast (or faster)

    • 8 Comments

    Compiling a complete NAV database can take quite a while. Even on powerful development machines with a lot of CPU cores this is still the case - the development environment wasn't designed for the multi-core era. The only way to speed things up is to use separate instances of the development environment and have each compile a (distinct) subset of the objects in the database. With the new Development Environment Commands for PowerShell that were included in the Microsoft Dynamics NAV 2015 Development Shell, this has become a lot easier.

    Before heating up those cores, let's first introduce the command that we need for this: Compile-NAVApplicationObject. In the following example we'll assume that the database and Development Shell reside on the same machine. To compile all non-compiled objects in a database named the command simply takes a parameter that specifies the database (i.e., MyApp) and optionally if and how schema changes should be synchronized:

    Compile-NAVApplicationObject -DatabaseName MyApp -SynchronizeSchemaChanges No

    To compile all objects in a database regardless their current compiled state use the Recompile switch:

    Compile-NAVApplicationObject -DatabaseName MyApp -SynchronizeSchemaChanges No -Recompile

    The command also takes a filter, e.g.:

    Compile-NAVApplicationObject -DatabaseName MyApp -Filter ID=1..100

    compiles all non-compiled objects with an ID in the range 1 to 100.

    Now to parallelize the compilation process we need to partition the set of objects in distinct sets that can be compiled in parallel. The most straightforward way to do this is based on object type. For each object type we can start a compilation job using the AsJob parameter. Using this parameter an instance of the development environment is started in the background and a handle to this background job is returned. PowerShell comes with a set of commands to work with jobs, for instance, to get the output of a job (Receive-Job) or to wait for a job to finish (Wait-Job). Occasionally, race conditions could occur while updating the object table. As a result, some objects may fail to compile. Therefore, after all background jobs have completed we compile all non-compiled objects in a final sweep. This is all we need to understand the following function that compiles all objects in a database in 7 parallel processes:

    function ParallelCompile-NAVApplicationObject
    (
    [Parameter(Mandatory=$true)]
    $DatabaseName
    )
    {
    $objectTypes = 'Table','Page','Report','Codeunit','Query','XMLport','MenuSuite'
    $jobs = @()
    foreach($objectType in $objectTypes)
    {
    $jobs += Compile-NAVApplicationObject $DatabaseName -Filter Type=$objectType -Recompile -SynchronizeSchemaChanges No -AsJob
    }

    Receive-Job -Job $jobs -Wait
    Compile-NAVApplicationObject $DatabaseName -SynchronizeSchemaChanges No
    }

      
    Just for fun, let's measure the performance gain. We can do this using Measure-Command:

    Measure-Command { Compile-NAVApplicationObject MyApp -SynchronizeSchemaChanges No -Recompile }
    Measure-Command { ParallelCompile-NAVApplicationObject MyApp } 

     

    These two screenshots from task manager illustrate the difference in CPU utilization: while running the non-parallel version CPU utilization is hovering around 40%; while running the parallel version CPU utilization is maxed out at 100%.

                 

                        

    On my laptop (with 2 CPU cores) compilation of the 4148 objects in the W1 application takes 8 minutes and 46 seconds using the non-parallel version; using the parallel version it takes only 4 minutes and 32 seconds. Machines with more CPU cores may produce even better results. Note that when parallelizing this way (i.e., based on object type) only four processes are active most of the time - compilation of Queries, XMLports and MenuSuites finishes relatively quick. So if you have a machine with a lot of cores (say 6 or 8) that you want to put to use, you need to find a way to partitioning the set of objects into a larger number of smaller sets.

    Who beats 4 minutes and 32 seconds? And please share how you did it!

Page 5 of 51 (757 items) «34567»