Microsoft Dynamics NAV

Team Blog

  • 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

    • 0 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

    • 0 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

    • 15 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.

    • 2 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!

  • Microsoft Dynamics NAV Team Blog

    Costing Update RollUp 2 for Microsoft Dynamics NAV 2009 SP1 and Microsoft Dynamics NAV 2009 R2 has been released

    • 4 Comments

    Costing Update RollUp 2 includes an update fixing 44 costing issues related to Microsoft Dynamics NAV 2009 SP1 and Microsoft Dynamics NAV 2009 R2.

    Where to find Costing Update RollUp 2

    You can download the update from KB 3011240 - Costing Update RollUp 2 for Microsoft Dynamics NAV 2009.

    For a full list of all hotfixes included in the update, see the KB article.

  • Microsoft Dynamics NAV Team Blog

    Welcome to the new Microsoft Dynamics NAV Dev Center on MSDN

    • 1 Comments

    We have moved the Microsoft Dynamics NAV dev center to a new platform, and we hope you are going to find it a good source of information going forward. The dev center is in the same location as before but looks somewhat differently. Remember good old grey? Well, it's gone - take a look here:

    http://msdn.microsoft.com/en-us/dynamics/nav/

    At the dev center, your and your coworkers can find the latest readiness videos for Microsoft Dynamics NAV 2015 and Microsoft Dynamics NAV 2013 R2. You will also find links to other getting-started content in the MSDN Library, and tips for other sources of information about developing solutions based on Microsoft Dynamics NAV. You can find links to the latest downloads of the product, including the latest cumulative updates, and direct links to the three app stores.

    We hope you will find the new dev center easier to navigate and less likely to contain outdated information. We plan to add more content to the dev center in the coming months, so add the dev center to your list of sites to check up on from time to time.

     

    Best regards

    Susanne and Eva from the NAV UA team

  • Microsoft Dynamics NAV Team Blog

    NAV Design Pattern - Currently Active Record

    • 1 Comments

    One of the good things about having the NAV Design Patterns project open to the community, is that we get to hear about the experiences and design considerations of the NAV partners, which brings to light practices from other places than MDCC. Find below a pattern described by Henrik Langbak and Kim Ginnerup, from Bording Data in Denmark.

    Best regards,

    The NAV Design Patterns team

    Meet the Pattern

    Date controlled data is expensive to find in the database. This pattern describes how using a view with a sub-select and a linked table object will minimize the returned dataset.
    A side effect is reduced and simplified code, increased performance and a more scalable solution that is almost independent of the amount of records in the table.

    Know the Pattern

    There is no way in Microsoft Dynamics NAV to get a set of records from the database, which all have the newest starting date, that is less than or equal to today’s date. Having an ending date on the record will help, but it introduces some other problems. In Microsoft Dynamics NAV, this is normally done by reading too many records, either at the SQL Server level or in the middle tier and throw away the ones you do not need. That is a waste of resources:

    • SQL Server reads too many records
    • Too much data sent over the network.
      (If SQL Server and Microsoft Dynamics NAV Server are on different machines.)
    • The Microsoft Dynamics NAV service tier receives and throw away data.

    Ending Date Problem

    Ending Date may introduce some problems of its own.

    If your design requires you, to have one and only one active record per key in a dataset, then Ending Date introduces the possibility for overlapping or holes in the timeline.
    Ending Date creates a dependency between two records. Changing a Starting Date, requires you to update the previous record. Changing the Ending Date requires you to update the next record.
    If you add a record in between you will have to update both the before and the after record.

    The pattern we describe here will work whether there is an Ending Date or Not.

    The pattern is also relevant for other types than date. The pattern is usable whenever you have dependencies between rows in a table. 

    Use the pattern whenever you read a set of data containing a Starting Date and you need to implement a loop to throw away unwanted records. An example could be Codeunit 7000 “Sales Price Calc. Mgt.”. In this codeunit there are many loop constructs to find prices and discounts.

    Use the Pattern

    In the following example, we have a fictive table containing: Code, Starting Date and Price. The Primary Key consist of Code, Starting Date. The Database is the Demo Database, and the Company is Cronus.

    1. Create the view

    You will need to create the view before you define the Table Object.
    You will need to create a view for every company in the database. 

    CREATE VIEW [dbo].[CRONUS$PriceView]
    AS
    SELECT [Code], [Starting Date], [Price]
    FROM dbo.[CRONUS$Price] AS A
    WHERE [Starting Date] =
            (SELECT MAX([Starting Date])
             FROM dbo.[CRONUS$Price] AS B
             WHERE B.[Code] = A.[Code] AND
                   B.[Starting Date] <= GETDATE())

    Test the view to ensure that you get the correct result. It is much easier to test now than later.

    2. Create the Table object

    Read more on the NAV Design Patterns Wiki...

  • Microsoft Dynamics NAV Team Blog

    Updated System Requirements for Microsoft Dynamics NAV 2015 Windows Client

    • 5 Comments

    The system requirements for Microsoft Dynamics NAV 2015 have been updated in the MSDN Library. In the original version, the section for the Windows client contain misleading information about the supported operating systems. This was a bug in the way that system requirements are gathered and tested, and we have changed the process accordingly. We are fully aware of the confusion that the misleading information about only supporting 64-bit editions has caused.

    The Microsoft Dynamics NAV 2015 Windows client supports both 32-bit and 64-bit editions of Windows 8.1, Windows 8, and Windows 7.

    As always, the latest version is in the MSDN Library at the following location: http://msdn.microsoft.com/en-us/library/dd301054(v=nav.80).aspx.

    Best regards,

    The NAV UA  team and the NAV Release Management team

Page 1 of 47 (693 items) 12345»