• Microsoft Dynamics NAV Team Blog

    Application Test Toolset for Microsoft Dynamics NAV 2009 SP1

    • 16 Comments

    The C/AL Application Test Toolset for Microsoft Dynamics NAV 2009 SP1 is now available on PartnerSource. This toolset helps NAV developers to quickly develop and run C/AL-based tests in their primary development environment.

    The toolset includes sample tests to help you get started with C/AL test development, tools for test case management and execution, and useful test library functions, such as assert and database state restore.

    These tools build on top of the Test Features released with Microsoft Dynamics NAV 2009 SP1.

    Download from PartnerSource

  • Microsoft Dynamics NAV Team Blog

    .NET Interoperability in NAV 2009 R2

    • 15 Comments

    The greatest development platform in the world meets the greatest set of functional libraries, types, methods, and properties as Microsoft Dynamics NAV 2009 R2 allows developers to take advantage of the Microsoft .NET Framework! With NAV 2009 R2, you can reference external .NET components and make use of the Types and Functions from .NET Framework assemblies and from your own or 3rd party code.

    Being able to use .NET from C/AL code has been planned for a long time - the whole NAV Server architecture released with NAV 2009 has been building to this time where we can finally reach out from the NAV C/AL context and make use of these functions. The feature is very much part of our roadmap going forward where we want to give developers more power and allow partners to create solutions with much broader reaches than can be achieved within a native C/AL environment.

    Referencing an external component will be similar to the pattern that Automation developers are accustomed to - you can quickly choose a component from the variable declaration window and then start using the object in C/AL with full support from NAV's Symbol Menu (F5). 

    When working with variables of type DotNet, we distinguish between two sorts: Add-ins and those registered from the Global Assembly Cache (GAC). The Add-in type are those that are custom made or custom written, they do not need to be strong-named, and they may also change or are updated often. These components must be copied into a new directory (the Add-ins directory) on the developer's C/SIDE installation in order to be utilized. Variables based on types registered in the GAC are less likely to be swapped around but support strong-named types and include components like the .NET Framework. .NET Framework components have the additional benefit that they are already deployed on computers so there is no need for additional deployment!

    Rather than elaborate more on the properties and definitions, let's look at a sample. In this code sample, we will use methods from the .NET Framework to retrieve a list of processes running on the NAV Server and show the process IDs in a message box. The sample is not exactly an ERP task but shows what can now be achieved by using .NET and hopes to show that familiar code patterns can be applied.

    This screenshot shows the whole solution:

    Notice that we have declared two DotNet variables here - myproclist, which is a System.Array and holds our list of processes, and process, which is a System.Diagnotics.Process subtype. Both variables are from the .NET Framework and are thus registered in the system GAC and we don't need to worry about deploying them for when we run the code.

    Notice also that unlike Automation (based on COM), you don't always need to CREATE the objects. In DotNet, objects need to have a constructor called when they are instance-based or they may be used directly if they are static. The GetProcesses method is a static method in .NET, as we can see in the information section in our ever-helpful Symbol Menu.

    Notice also that the C/AL code is able to loop through the Array. Using arrays (be they NAV arrays or .NET System.Arrays) is such a common programming pattern that it would be very wrong of us to not include it.

    Of course using .NET is only supported on the NAV Server and, like Automation, you can also run the .NET objects either on the NAV Server or on the RoleTailored client.

    Using .NET in C/AL will open many new options - more than we can possibly imagine. We hope you'll enjoy using this feature from NAV 2009 R2 and go on to make some fantastic new solutions for all our customers!

    Good luck and happy coding!

    Stuart

    To view a recorded version of the Hot Topic session about .NET Interoperability, see the Partner Learning Center.

  • Microsoft Dynamics NAV Team Blog

    Microsoft Dynamics NAV 5.1 becomes 6.0; Delivery Date H1 of 2008 becomes H2 of 2008

    • 15 Comments

    Nobody ever wants to miss a commitment that they make, and with the move of our delivery date from H1 to H2 of 2008, that is the situation we as a Dynamics NAV R&D team find ourselves in right now.  This reality is very disappointing for all of us, and definitely not what we hoped for , but I have to say that I am as excited as I have ever been about the product we are building and I am confident that you will find that the product will definitely be worth the additional wait.

    With our next version of Dynamics NAV we are making incredible leaps forward on the user experience and technology platform of the product. It was important that the market, our partners, and our customers understand the magnitude of this advance, thus we have updated the code name for this version from 5.1 to “6.0”. It is at minimum a full version worth of progress. The advances we have made include:

    ·         We have moved the product from a two-tier architecture to a three-tier architecture dramatically increasing the integration opportunities for customers.

    ·         We have added support for web services across the board and enabled all of our ISV and partner solutions to also be web serviced enabled. The win for customers is the ability to leverage the open interface from multiple applications in their organizations.

    ·         We have transitioned our runtime execution engine from an interpreted environment to a compiled environment running on.NET. Giving customers increased performance and stability and aligning us even closer with the advances being on the Microsoft Stack.

    ·         We have transitioned our reporting story to Microsoft SQL Server Reporting Services and the incredible richness that it provides for users to gain more insight into their business.

    ·         We have added a deep integration with Office SharePoint Services making it even easier to get more people in an organization working with your business system.

    ·         Finally, and most dramatically and importantly, we’ve made a MAJOR upgrade to a new Role Tailored User Experience that our research indicates that customers will absolutely Love.

    We are accomplishing this while at the same time working to ensure that we preserve customer and partner investments. This requires a robust set of transformation tools and processes in addition to the core product advancements.

    We are introducing a lot of change and we must make sure to get it right. Why the change in date?  Well there are a few reasons:

    ·         First, we just were not tracking towards the plan we had created, and we were not going to make the planned H1 2008 date.

    ·         Second, we are closely monitoring the performance and simplicity of the new 3-tier model. As a result, we made some adjustments to our designs to increase our performance and the simplicity of our install.

    ·         Third, we’ve made a huge commitment to getting more feedback on this release before shipping.  We will provide code much earlier in the release cycle in order to maximize the feedback that we can receive and process. I will talk more about this later.

    As a result of our decision to move the date of “6.0” we decided that it would possible to pull some of the work we were doing in “6.0” forward into a Service Pack for 5.0. That work includes:

    ·         We are going to deliver Dynamics Mobile support for Dynamics NAV as part of the service pack and for Dynamics NAV 4.0. This feature will allow our partners to create mobile solutions that are occasionally connected and fully integrated with Dynamics NAV.

    ·         We brought forward a number of Microsoft SQL data access improvements. These will increase both the performance and scalability of the product.

    ·         We have added a collection of small features that have been highly requested over the years.

    ·         We have rolled up a number of the improvements and corrections that have been done since version 5.0 shipped.

    ·         We will expand the number of countries that will have version 5.0 in their markets.

    Dynamics NAV 5.0 is a great release, and with these additions it will be even better. Because of the investment we’ve made in the transition process from 5.0 to “6.0” customers and partners should not hesitate to make the move to 5.0 now.

    Earlier I mentioned that we are increasing our feedback process before we release “6.0”. Here is some of what we are planning at this point:

    ·         In November at the Directions Conference in Orlando, the entire NAV R&D leadership team will be there to do an entire day of sessions, running the current “6.0” code, discussing the transformation process, showing our new concepts, and working to gather as much input as we can. We will also provide a set of pre-recorded step by step demos of the “6.0” product that can be used to build familiarity with the product.

    ·         Also in November we will deliver a preview version of the product to 50 ISV’s who are part of our early adopter program. These partners have committed to working with the product and providing us with feedback. This drop will be of our core release.

    ·         In Q1 and Q2 of 2008 we will release updated previews to the entire partner community . These will be early availability drops and will need to be treated as such; our intent is to gather feedback on quality, performance, and any transition process issues that partners can identify.

    ·         The Q2 version will also be localized to a selected number of countries, and we will be working with a small number of partners and customers to work on transitioning their solutions onto the “6.0” product. 

    ·         The final beta will be provided in Q3 and we will deliver a version for select countries that we will use with our early adopter customers to take them live on the product. By going through the full implementation process and getting end user feedback we are confident that we will have exercised the product to the level where we can all be confident in the solution

    As a Dynamics R&D team we are extremely committed to this plan and we are doing everything we can to make sure we get feedback, react to the feedback, and deliver a high quality solution.

    The team and I are really, really, really excited about the product we are bringing your way.  I sincerely hope that this quick glimpse behind the scenes into our delivery plan increases both your confidence and anticipation of where we are taking Dynamics NAV.  With well over 1,000,000 users today Dynamics NAV is already a great product, Version 5.0, Version 5.0 SP1 and Version “6.0” are moving it forward towards and even better future. It is a ride you will most definitely want to be a part of.

    Darren Laybourn

  • Microsoft Dynamics NAV Team Blog

    Saying Farewell to the Native Database

    • 14 Comments
    I've met many people who imagine that everyone who works at Microsoft must be of a single mind, with one goal - much like a hive mentality. Nothing could be further from the truth. We are an organization of individuals, often passionate about our beliefs and very emotionally invested in the work that we do. We're very proud of our successes and we want to learn from our failures. We're very human. And as such, when I was asked to work with a team that would decouple the NAV product from our native database, it was with an element of sadness that I agreed. I can also admit that I wanted to do the job because, like many of you, I've worked with this product for over a decade and I wanted this one to happen by someone who understood what we were saying farewell to.    

    You shouldn't be burdened with the technical details about decoupling the files from our build system, generating the lists of extra dlls that we no longer need to install, or reviewing documentation that has references to the database format. When we are about to commit a huge change like this to our internal systems, we send an email to all team members informing them of an impending ‘Breaking Change' and to give teams a last chance to speak up about the impact this will have in their work cycles. There were almost no issues raised but I did receive a large number of comments from team members along the lines of "are you sure we want to take this away," "aren't we giving up the NAV simplicity," and "this is sad."  And a part of me agreed.

    But it's not really sad. The day we committed this change was a bit like the last day of High School. We've all had a fabulous time but our future is ahead.

    It's not sad because the original goal of Navision was not to become a best of breed database product - we wanted to build business applications. We happened to build a very clever little database at the same time but it was never the goal to have the database as the reason that people buy NAV.

    It's not sad because now we focus on SQL Server and we can ensure that SQL is the platform we do our enhancements on. And aim to improve performance on. And benchmark on.

    We can spare our Quality Assurance (Test) organization the pain of testing on a legacy platform and double our efforts into the SQL stack. We can spare our developers from maintaining data connections for two different platforms and spare ourselves the discussion about how to take advantage of SQL features without impacting the way the native database is used. 

    I'm looking forward to everything we can now do and I hope you will join us too.

    -Stuart Glasson

    For more information about the Statement of Direction for Microsoft Dynamics NAV where we talk about ending support for the native NAV database, see this blog post.

  • Microsoft Dynamics NAV Team Blog

    Creating a web service manually, the importance of the name you give it, and a few small things to remember

    • 14 Comments

    When you use the SC command line command to create a new NAV 2009 Service, how does the new service know whether it is a middle tier for RTC to connect to, or whether it is supposed to handle web service calls?

    In other words, what decides whether the new service will be "Microsoft Dynamics NAV Server" or "Microsoft Dynamics NAV Business Web Services"?

     

    It depends on the name. If it starts with "MicrosoftDynamicsNavWS", then it will be for Web Services. If the name starts with anything else, then it will be for middle tier for RTC clients.

     

    To keep things simple, just give your NAV Servers names beginning with MicrosoftDynamicsNAV / MicrosoftDynamicsNAVWS. Then if you need a second, third, etc server, add a unique name, seperated by a $-sign, for example:

    MicrosoftDynamicsNAV$Svr2

    MicrosoftDynamicsNAVWS$Svr2

     

    Here are the simple steps for how to create a new web service service, and a few more things to be aware of. Let's say that we want to start a second set of NAV Servers.

     

    First create the normal service from a command prompt:

    SC CREATE "MicrosoftDynamicsNAV$Svr2" binpath= "C:\Program Files\Microsoft Dynamics NAV\60\Service2\Microsoft.Dynamics.Nav.Server.exe" DisplayName= "MSSvr2"

    Then create the service for Web Services: 

    SC CREATE "MicrosoftDynamicsNAVWS$Svr2" binpath= "C:\Program Files\Microsoft Dynamics NAV\60\Service2\Microsoft.Dynamics.Nav.Server.exe $Svr2" DisplayName= "MSWSSvr2" type= share

     

    The additional settings you must provide as marked in bold above, and a few things that you must remember are:

     

    1)  The Name

    As described, the name must begin with MicrosoftDynamicsNAVWS if you want it to be for web services

     

    2)  Include the last part of the name in BinPath

    After the .exe in the binpath parameter you must specify the part of the name ($Svr2 in this case) that comes after MicrosoftDynamicsNAVWS. If you forget this step, you might get this error when you try to start the service:

    Windows could not start the MSWSSvr2 service on Local Computer.Error 1083: The executable program that this service is configured to run in does not implement the service.


     

    3)  Type must be share

    For the service that handles web services, add the parameter type= share. Otherwise the service will still try to start up as a middle tier (not for web services).

     

    4)  Spaces after =

    You must remember the space after each = in the command, as in for example "type= share". This is just the syntax of the SC-command.

     

    5)  DisplayName

    It doesn't matter what display name you give - this is just to find it in Services.

     

    These are just some of the small things to keep in mind. For many more details on web services go to Freddys blog, especially this post:

    Multiple Service Tiers - SP1

     

    // Lars Lohndorf-Larsen

     

  • Microsoft Dynamics NAV Team Blog

    Send email with PDF attachment in NAV 2009

    • 13 Comments

    In this post I would like to explore the possibilities to create an email from the Role Tailored client and attach an invoice as a PDF file to the email, unfortunately we have do not have this functional build into our Demo application, but let me show you how this can be do with little effort.

    First I suggest you download the fob file which contains the 5 different options I will go through here.

    When downloaded the fob file you will see that I have added 5 new actions

    image

    1. SendAsPDF(Use of codeunit to rename) recommended solution
    2. SendAsPDF(Access to Server needed)
    3. SendAsPDF(With Temp file name)
    4. SendAsPDF(User prompted to save)
    5. SaveAsPDFrecommended solution(if you just want the PDF file)

    Let me go through the different options starting from the bottom, since I recommend option 1, but I would also like to share other options for doing this, since these might be valuable for you.

    Option 5: SaveAsPDF
    In this option you will get prompted if you want to open or save the PDF. The PDF file created will be based on the select Invoice in the Posted Sales Invoices List Place

    image 

    In this option all I do is to have the server create the PDF file for me and use the new download function in NAV 2009 to retrieve the PDF file created on the server.

    Option 4: SendAsPDF(User prompted to save)
    In this option, you will first be prompted to save the file.
    Here it is important to select to “”SAVE” the PDF file on the disk, to have the correct name of the PDF file. If you select to “OPEN” the PDF filename will be given a temp name.

    After you have saved the PDF we now create the email message you will get 3 messages similar to this when this happens:

    image

    You get these message because we connect to an external component(Outlook) to the Role Tailored client. It is of course up to you if you want to set this to “Always allow”, but this would remove these messages, the next time you open the Role Tailored client.

    When you have allowed these to run, email will be created with the PDF file attached.

    image

    In this option all I do is to download the PDF to the client and then use the Mail codeunit to create the email

    Option 3: SendAsPDF(With Temp file name)
    In this option, you will not be prompted to save the PDF file.
    And the email will be created immediately. This would probably be the preferred compared to downloading this to the user disk, but we will use the PDF file created on the server, and since this file get a TEMP name, like this: “__TEMP__570eb0279b9d4b1fa837caf3a14acbf7” this option is not really good.

    Let us look at the option 1 and 2 where this issue is solved.

    Option 2: SendAsPDF(Access to Server needed)
    In this option you will not be prompted to save the file either, but here the end user will need to have access the server folder where the PDF is stored on the server. In some situation you might want this, but for security reasons you might also not want to give this access to the user.

    Option 1: SendAsPDF(Use of codeunit to rename) recommended solution
    Again in this option you will not be prompted to save the PDF file, but the PDF file will be automatically added to the email. In this option we have build a codeunit to rename the TEMP file created on the server, and end user will not need to have access to any folders on the server.

    So all in all I recommend option 1 for attaching PDF file to an email. And once again I have made all the code available here, so feel to be explore how I build this. If you feel there is an option that I missed, feel free to leave a commit or use the contact form Email.

    Thanks,
    Claus Lundstrøm, Program Manager, Microsoft Dynamics NAV

  • Microsoft Dynamics NAV Team Blog

    NAV 2013 - Reports may be difficult to read when printing over Terminal Services

    • 13 Comments

    === Blog updated on March 4th ====

    Updated with the good news that we now have a hotfix for this for Windows Server 2008 R2:

    Visual elements are displayed incorrectly etc... - KB 2768741.

    ===== end of update ===========

     

     

    In NAV 2013, if you run the Windows Client via a Terminal Server or Remote Desktop Connection (RDC) or some common 3rd party application host technology, reports may be difficult to read when you print them. Preview looks fine.

     

    A report could look like this in preview (OK):

     

     

     

    But in Print Layout rendering or when printing to paper it would look like this - notice it looks like the fonts have been scrunched and it's hard to read:

     

     

     

    When does this happen?

     

    It happens when

      A)  you run NAV 2013 via a Terminal Server or via Remote Desktop Connection (RDC), and

      B)  the screen resolution on the connection is not 4/3, and

      C)  the Terminal Server machine is running Windows 2008 including Windows 2008 R2.

     

     

    The screen resolution is the important thing here. If we use a screen resolution of 4/3 (=1.33333) then all works fine. So if my RDC looks like this then I don't have this issue:

     

    On this connection the screen resolution in my connection is 1024 by 768. 1024 / 768 = 1.33333, and everything is OK.

     

     

    But if I set the screen resolution on my RDC like this:

     

     

    Then my screen resolution = 1366 / 768 = 1.779.

    1.779 <> 1.33333 and then I have the problem.

     

     Why?

     

    The root of the problem lies in graphics rendering (GDI) in Windows 2008 when it tries to scale from a screen resolution which is not 1.33333. In Windows 2012, rendering was redesigned to take advantage of hardware acceleration and ActiveX as described in this article:

    Windows 8 graphics: Microsoft has hardware accelerated all the things

    So we do not have this problem if the host machine is running Windows 2012.

    NAV 2013 uses a newer version of Report Viewer which relies more on Windows GDI than previously, which is why we have only started seeing this problem on NAV 2013 installations.

     

     

    So what can we do?

    Based on the above there are three ways out of this problem:

    1)  Ensure that all users use a screen resolution of 4/3

    2)  Avoid a host machine trying to scale a client's resolution. For example:

      - Save the report to PDF, then print from the PDF document. PDF rendering is not affected by this issue.

      - Use server-side printing - for example make use of the Job queue and let NAS print reports. Then the server can ignore what resolution the client has.

      - Use other ways than Terminal Server to simplify client installations, such as ClickOnce or possibly "Remote Apps". In this way the client runs on the local machine and not on a host machine.

    3)  Upgrade the Terminal Server / RDC host machine to Windows 2012. Client machines do not need to be upgraded.

     

     

    Workarounds 1) and 2) could be hard to enforce in some cases. But knowing about this issue, hopefully the option of using Windows 2012 can be considered.

     

     

     We will post updates here if and when we find any further details around this issue!

     

     

     

     

     

     

     

  • Microsoft Dynamics NAV Team Blog

    Installing Microsoft Dynamics NAV 2013 R2 side-by-side with Microsoft Dynamics NAV 2013

    • 12 Comments

    A year after Microsoft Dynamics NAV 2013 released, we released a new version of it, Microsoft Dynamics NAV 2013 R2. They share common files, so if you install both versions on the same computer, then they will try to use the same resources, and so you run into problems. This really means that you cannot install the two versions side-by-side.

    We resolved this issue with the fix in KB 2907588 for Microsoft Dynamics NAV 2013 R2 (build number higher than 35850). But there is some manual work that you have to do to apply the fix fully.
    Microsoft Dynamics NAV 2013 and Microsoft Dynamics NAV 2013 R2 use the same Windows registry entries to describe which interface and libraries to use. With the described fix, Microsoft Dynamics NAV 2013 R2 can use new registry entries, but simply installing the hotfix does not generate the registry entries. Windows registry settings are created by installation programs, but creating a new installer for every language is out of scope for hotfix releases.

    To get Microsoft Dynamics NAV 2013 and Microsoft Dynamics NAV 2013 R2 working side-by-side, you can choose to modify some of the existing entries in the Windows registry. But the easiest way is to delete the existing registry entries and create new entries in the registry.

    Depending on the specific machine architecture, your registry settings can include the following entries:
    " HKEY_CLASSES_ROOT\TypeLib\{5020AC1E-A4F0-402B-A920-3FED4E3B05CC}\7.1"
    " HKEY_CLASSES_ROOT\Interface\{14519985-4959-4F7C-AC30-CBBCD9DFBC08}"
    " HKEY_CLASSES_ROOT \Interface\{59521B62-D441-47E6-8224-A07203686BA2}"
    " HKEY_CLASSES_ROOT \Wow6432Node\TypeLib\{5020AC1E-A4F0-402B-A920-3FED4E3B05CC}\7.1"
    " HKEY_CLASSES_ROOT \Wow6432Node\Interface\{14519985-4959-4F7C-AC30-CBBCD9DFBC08}"
    " HKEY_CLASSES_ROOT \Wow6432Node\Interface\{59521B62-D441-47E6-8224-A07203686BA2}"

    Remove the entries.

    To create new correct windows registry entries, open the Command Prompt as an administrator, and then, run the RegAsm.exe /register Microsoft.Dynamics.Nav.Client.WinForms.dll /tlb command for each of the two products.

    For example, for Microsoft Dynamics NAV 2013, enter the following command:

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe /register "C:\Program Files (x86)\Microsoft Dynamics NAV\70\RoleTailored Client\Microsoft.Dynamics.Nav.Client.WinForms.dll" /tlb

    And for Microsoft Dynamics NAV 2013 R2, enter the following command:
    C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe /register "C:\Program Files (x86)\Microsoft Dynamics NAV\71\RoleTailored Client\Microsoft.Dynamics.Nav.Client.WinForms.dll" /tlb

    When you have run those two commands on a 32-bit computer, the following entries exist in the registry:

    Microsoft Dynamics NAV 2013:
    HKEY_CLASSES_ROOT\Interface\{14519985-4959-4F7C-AC30-CBBCD9DFBC08} (where \TypeLib\Version == 7.0)
    HKEY_CLASSES_ROOT\TypeLib\{5020AC1E-A4F0-402B-A920-3FED4E3B05CC}\7.0

    Microsoft Dynamics NAV 2013 R2:
    HKEY_CLASSES_ROOT\Interface\{59521B62-D441-47E6-8224-A07203686BA2} (where \TypeLib\Version == 7.1)
    HKEY_CLASSES_ROOT\TypeLib\{95819FD3-CF0A-4706-BE93-35B3DDCB817C}\7.1

    And for 64-bits computers:
    Microsoft Dynamics NAV 2013:
    HKEY_CLASSES_ROOT\Interface\{14519985-4959-4F7C-AC30-CBBCD9DFBC08} (where \TypeLib\Version == 7.0)
    HKEY_CLASSES_ROOT\Wow6432Node\Interface\{14519985-4959-4F7C-AC30-CBBCD9DFBC08} (where \TypeLib\Version == 7.0)
    HKEY_CLASSES_ROOT\TypeLib\{5020AC1E-A4F0-402B-A920-3FED4E3B05CC}\7.0
    HKEY_CLASSES_ROOT\Wow6432Node\TypeLib\{5020AC1E-A4F0-402B-A920-3FED4E3B05CC}\7.0

    Microsoft Dynamics NAV 2013 R2:
    HKEY_CLASSES_ROOT\Interface\{59521B62-D441-47E6-8224-A07203686BA2}(where \TypeLib\Version == 7.1)
    HKEY_CLASSES_ROOT\Wow6432Node\Interface\{59521B62-D441-47E6-8224-A07203686BA2}(where \TypeLib\Version == 7.1)
    HKEY_CLASSES_ROOT\TypeLib\{95819FD3-CF0A-4706-BE93-35B3DDCB817C}\7.1
    HKEY_CLASSES_ROOT\Wow6432Node\TypeLib\{95819FD3-CF0A-4706-BE93-35B3DDCB817C}\7.1

    If you have applied everything correctly, then Microsoft Dynamics NAV 2013 and Microsoft Dynamics NAV 2013 R2 will now both be able to run on the computer.

    If you have only Microsoft Dynamics NAV 2013 R2 installed and any object run from dev env opens new RTC instance, then you can apply the same registry modify (related to 7.1) and issue will be resolved.

    Attached is PowerShell script does all job.
    BTW: If Microsoft Dynamics NAV 2013 R2 is installed alone, you can also use script - it will fix registries. 

     

    Best regards,

    Gedas Busniauskas and Jorge Alberto Torres from the Dynamics NAV team

  • Microsoft Dynamics NAV Team Blog

    Microsoft Dynamics NAV/SQL Server Configuration Recommendations

    • 12 Comments

    Michael De Voe, a Senior Premier Field Engineer at Microsoft, has compiled a set of recommendations for SQL Server configuration to improve performance when running Microsoft Dynamics NAV 5.0 and later versions with one of the following versions of SQL Server:

    • Microsoft SQL Server 2005 SP3 x64
    • Microsoft SQL Server 2008 SP1 x64
    • Microsoft SQL Server 2008 R2 x64

     The attached document contains Michael's recommendations, including the following options and parameters:

    • Max Server Memory
    • Auto-Create Statistics
    • Auto-Update Statistics
    • Auto-Grow
    • Database Compatibility Level
    • Trace Flag 4136
    • Trace Flag 4119
    • Data files for TempDB
    • Disk Alignment
    • Read Committed Snapshot Isolation (RCSI)
    • Max Degree of Parallelism
    • Dynamics NAV Default Isolation Level
    • Dynamics NAV "Lock Timeout"
    • Dynamics NAV "Always Rowlock"
    • Maintenance Jobs
    • Instant File Initialization
    • Optimize for Ad Hoc Workloads
    • Page Verify
    • Lock Pages in Memory

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

  • Microsoft Dynamics NAV Team Blog

    Test Automation Series 1 - Test Data

    • 12 Comments

    This post discusses the use of test data when developing automated tests based on the testability features that were released with Microsoft Dynamics NAV 2009 SP1. The practices outlined here have been applied during the development of the tests included in the Application Test Toolset for Microsoft Dynamics NAV 2009 SP1.

    Overall, the execution of automated tests proceeds according to a four-phased pattern: setup, exercise, verify, teardown. The setup phase is used to place the system into a state in which it can exhibit the behavior that is the target of a test.  For data-intensive systems such as Dynamics NAV, the test data is an important part of setting system state.  To test the award of discounts, for instance, the setup phase may include the creation of a customer and setting up a discount.

    One of the biggest challenges of testing software systems is to decide what test data to use and how and when to create it.  In software testing the term fixture is used to describe the state in which the system under test must be to expect a particular outcome when exercised. The fixture is created in the Setup phase. In the case of an NAV application that state is mostly determined by the values of all fields in all records in the database. Essentially, there are two options for how to create a test fixture:

    1. Create the test fixture from within each test.
    2. Use a prebuild test fixture which is loaded before the tests execute.

    The advantage of creating the fixture in the test is that the test developer has as much control over the fixture as possible when tests execute. On the other hand, completely creating the test fixture from within a test might not be feasible in terms of development effort and performance. For example, consider all the records that need to be created for a simple test that posts a sales order: G/L Setup, G/L Account, General Business Posting Group, General Product Posting Group, General Posting Setup, VAT Business Posting Group, VAT Product Posting Group, Customer, Item, and so forth.

    The advantage of using a prebuild test fixture is that most data required to start executing test scenarios is present. In the NAV test team at Microsoft, for instance, much of the test automation is executed against the same demonstration data that is installed when the Install Demo option is selected in the product installer (i.e., CRONUS). That data is reloaded when necessary as tests execute to ensure a consistent starting state.

    In practice, a hybrid approach is often used: a common set of test data is loaded before each test executes and each test also creates additional data specific to its particular purpose.

    To reset the common set of test data (the default fixture), one can either execute code that (re)creates that data or restore an earlier created backup of that default fixture. The Application Test Toolset contains a codeunit named Backup Management. This codeunit implements a backup-restore mechanism at the application level. It may be used to backup and restore individual tables, sets of tables, or an entire company. Table 1 lists some of the function triggers available in the Backup Management codeunit. The DefaultFixture function trigger is particularly useful for recreating a fixture.

    Table 1 Backup Management

    DefaultFixture

    When executed the first time, a special backup will be created of all the records in the current company. Any subsequent time it is executed, that backup will be restored in the current company.

    BackupSharedFixture(filter)

    Creates a special backup of all tables included in the filter.

    RestoreSharedFixture

    Restores the special backup that was created earlier with BackupSharedFixture.

    BackupDatabase(name)

    Creates a named backup of the current company.

    RestoreDatabase(name)

    Restores the named backup in the current company.

    BackupTable(name,table id)

    Creates a backup of a table in a named backup.

    RestoreTable(name, table id)

    Restores a table from a named backup.

    There are both maintainability and performance perspectives on the creation of fixtures. First there is the code that creates the fixture. When multiple tests use the same fixture it makes sense to prevent code duplication and share that code by modularizing it in separate (creation) functions and codeunits.

    From a performance perspective there is the time required to create a fixture. For a large fixture this time is likely to be a significant part of the total execution time of a test. In these cases it could be considered to not only share the code that creates the fixture but also the fixture itself (i.e., the instance) by running multiple tests without restoring the default fixture. A shared fixture introduces the risk of dependencies between tests. This may result in hard to debug test failures. This problem can be mitigated by applying test patterns that minimize data sensitivity.

    A test fixture strategy should clarify how much data is included in the default fixture and how often it is restored. Deciding how often to restore the fixture is a balance between performance and reliability of tests. In the NAV test team we've tried the following strategies for restoring the fixture for each

    1. test function,
    2. test codeunit,
    3. test run, or
    4. test failure.

    With the NAV test features there are two ways of implementing the fixture resetting strategy. In all cases the fixture (re)creation code is modularized. The difference between the approaches is where the fixture creation code is called.

    The fixture can be reset from within each test function or, when a runner is used, from the OnBeforeTestRun trigger. The method of frequent fixture resets overcomes the problem of interdependent tests, but is really only suitable for very small test suites or when the default fixture can be restored very quickly:

    [Test]
    
    PROCEDURE Test()
    BackupManagement.DefaultFixture;
    // test code
    ...

    An alternative strategy is to recreate the fixture only once per test codeunit. The obvious advantage is the reduced execution time. The risk of interdependent tests is limited to the boundaries of a single test codeunit. As long as test codeunits do not contain too many test functions and they are owned by a single tester this should not give too many problems. This strategy may be implemented by the test runner, the test codeunit's OnRun trigger, or using the Lazy Setup pattern.

    With the Lazy Setup pattern, an initialization function trigger is called from each test in a test codeunit. Only the first time it is executed will it restore the default fixture. As such, the fixture is only restored once per test codeunit. This pattern works even if not all tests in a test codeunit are executed or when they are executed in a different order. The Lazy Setup may be implemented like:

    LOCAL PROCEDURE Initialize();
    
    IF Initialized THEN
    EXIT;
    BackupManagement.DefaultFixture;
    // additional fixture setup code
    ...
    Initialized := TRUE;
    COMMIT

    [Test]
    PROCEDURE Test_A()
    Initialize;
    // test code scenario A ...

    [Test]
    PROCEDURE Test_B()
    Initialize;
    // test code scenario B ...

     As the number of test codeunits grows the overhead of recreating the test fixture for each test codeunit may still get too large. For a large number of tests, resetting the fixture once per codeunit will only work when the tests are completely insensitive to any change in test data. For most tests this will not be the case.

    The last strategy only recreates the test fixture when a test fails. To detect failures caused by (hidden) data sensitivities, the failing test is then rerun against the newly created fixture. As such, some type of false positives (i.e., test failures not caused by a product defect) can be avoided. To implement this strategy the test results need to be recorded in the OnAfterTestRun trigger of the test runner to a dedicated table. When the execution of a test codeunit is finished, the test results can be examined to determine whether a test failed and the test codeunit should be run again.

    For the implementation of each of these fixture strategies it is important to consider any dependencies that are introduced between test codeunits and the test execution infrastructure (e.g., test runners). The consequence of implementing the setup of the default fixture in the test runner codeunit may be that it becomes more difficult to execute tests in other contexts. On the other hand, if test codeunits are completely self-contained it becomes really easy to import and execute them in other environments (e.g., at a customer's site).

  • Microsoft Dynamics NAV Team Blog

    Using the Quick Filter in Microsoft Dynamics NAV

    • 12 Comments

    Many of you that have installed Microsoft Dynamics NAV 2013 R2 have for sure noticed that the quick filter behavior has been redesigned in this release and that is why, in this post, we will go through all the changes and the intention behind them.

     

    So let’s start with a bit of history; the first version of the quick filter was released in the Microsoft Dynamics NAV 2009 Windows client, where we replaced the filter window available in the development environment with a filter pane integrated on all Microsoft Dynamics NAV pages. Here the user both has the option of entering filter criteria as plain text and the ability of composing an advanced filter. If you would like to quickly search for a certain record, the recommended practice is to use the quick filter.

    Let’s say, for example, that we want to find a contact in the contact list starting with “Man”. We can construct the filter by selecting the Name field and entering the text “man” in the search field.

    Notice that all the contacts starting with “man” now appear in the results list. How is this working? Whatever we add to this filter will be internally translated to a string by adding ‘@’ in front and ‘*’ in the end. So our filter string ‘man’ becomes ‘@man*’ and the Windows client filters for any contact name that starts with “man” in upper or lower case.  

    The following table illustrates more Quick Filter search examples in Microsoft Dynamic NAV 2013.

    Search Criteria

    Interpreted as…

    Returns…

    Man

    @man*

    All records that start with the string man and case insensitive.

    Se

    @se*

    All records that start with the string se and case insensitive.

    Man*

    Starts with Man and case sensitive

    All records that start with the string Man

    'man'

    An exact string and case sensitive

    All records that match man exactly

    *1

    Ends with 1

    All records that end with 1

    @*man

    Ends with and case insensitive

    All records that end with man

    @man*

    Starts with and case insensitive

    All records that start with man

    As part of our development process we regularly perform usability studies and some of them showed the users instinctively thought of the quick filter as a search field and that is why we decided to modify the quick filter behavior to a “contains” rather than a “starts with”. So what does this mean?

    Let’s construct the same filter in the Microsoft Dynamics NAV 2013 R2. Notice that the search results list includes contact names which start with “Man” and even have “Man” in the middle of the name. 

    What has changed? The entered filter will be translated to a string by adding ‘@*’ in front and ‘*’ in the end. So our filter string ‘man’ becomes ‘@*man*’ and the Windows client filters for any contact name that contains “man” in upper or lower case.  

    To start with in the RTM version of Microsoft Dynamics NAV 2013 R2 we have considered the simple user approach where the special characters in the filter criteria are ignored. However, in the Cumulative Update 13 for Microsoft Dynamics NAV 2013, we have refined the user experience and now respect the entered filter criteria.

    The following table illustrates the Quick Filter search examples for the Cumulative Update 13 and later for Microsoft Dynamics NAV 2013.

    Search Criteria

    Interpreted as…

    Returns…

    Man

    @*man*

    All records that contain the string man and case insensitive.

    Se

    @*se*

    All records that contain the string se and case insensitive.

    Man*

    Starts with Man and case sensitive

    All records that start with the string Man

    'man'

    An exact string and case sensitive

    All records that match man exactly

    *1

    Ends with 1

    All records that end with 1

    @*man

    Ends with and case insensitive

    All records that end with man

    @man*

    Starts with and case insensitive

    All records that start with man

    We encourage you to check out the Cumulative Update 13 and we hope that this blog demystifies some of the behavioral differences of the quick filter across Microsoft Dynamics NAV product versions.

  • Microsoft Dynamics NAV Team Blog

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

    • 11 Comments

    Cumulative update 8 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
      • 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

    Cumulative update 8 also introduces new functionality for exporting and importing companies and other data. You can export a company from a Microsoft Dynamics NAV database and import it into another database, and you can export and import other types of data such as global data, application data, and application objects.

    In earlier versions of Microsoft Dynamics NAV, you exported and imported this type of data as part of backing up and restoring databases. In Microsoft Dynamics NAV 2013 R2 CU8, you can do this by using the Export-NAVData and Import-NAVData Windows PowerShell cmdlets. You can also import and export data in the Microsoft Dynamics NAV Windows client.

    For more information, see the following documents on the W1 version of the Microsoft Dynamics NAV 2013 R2 CU8 download media:

    • MicrosoftDynamicsNAV2013R2CU8_ExportImportDataUsingNavDataFiles.pptx
    • MicrosoftDynamicsNAV2013R2CU8_ImportExportData.pdf

    Please note that there is very limited support for exporting and importing data in the Microsoft Dynamics NAV Web client. Use the Microsoft Dynamics NAV Windows client or the Windows PowerShell cmdlets instead.

    Where to find cumulative update 8

    You can download cumulative update 8 from KB 2971746 – Cumulative Update 8 for Microsoft Dynamics NAV 2013 R2 (Build 36897).

    For a full list of all hotfixes included in cumulative updates for Microsoft Dynamics NAV 2013 R2, see the following CustomerSource and PartnerSource pages: 

    CustomerSource:

    PartnerSource

    More Information

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

  • Microsoft Dynamics NAV Team Blog

    Coming Soon: Exporting and Importing Companies and Other Data

    • 11 Comments

    We are not quite ready yet, but we will soon announce the availability of new functionality for Microsoft Dynamics NAV 2013 R2: The ability to export business data, global data, and/or applications from one database and import the data into another database. Many of you used the FBK functionality to do this in earlier versions of Microsoft Dynamics NAV, but since we removed that backup/restore functionality in Microsoft Dynamics NAV 2013 R2, you have let us know how much you relied on it in your daily work. So we are working hard on this new functionality, and we will make an announcement when you can download the update.

    When the update is available, we will also update the Microsoft Dynamics NAV 2013 R2 Release Notes Follow-Up document, which is available here: https://mbs.microsoft.com/downloads/customer/NAV/NAV%202013%20R2/MicrosoftDynamicsNAV2013R2_ReleaseNotesFollowup.pdf

    Best regards,

    The Dynamics NAV team

  • Microsoft Dynamics NAV Team Blog

    Microsoft Dynamics NAV 2013 Compatiblity with Microsoft Windows 8 and Microsoft Windows Server 2012

    • 11 Comments

    We are proud to announce that Microsoft Dynamics NAV 2013 is compatible with Microsoft Windows 8 and Microsoft Windows Server 2012.

    We support the following versions of Microsoft Dynamics NAV with Microsoft Windows Server 2012 and Microsoft Windows 8:

    • Microsoft Dynamics NAV 2009 R2
    • Microsoft Dynamics NAV 2013

    For more information about requirements, see System Requirements for Microsoft Dynamics NAV 2013.

  • Microsoft Dynamics NAV Team Blog

    Coming Soon: Enabling Commerce Gateway for Microsoft Dynamics NAV 2013

    • 10 Comments

    With Commerce Gateway for Microsoft Dynamics NAV, companies can use Microsoft Dynamics NAV to electronically exchange trading documents with business partners regardless of conversion requirements and data formats. This helps streamline business processes and reduce transaction costs. Commerce Gateway also makes it easier for companies to meet the changing demands of their trading partners, regardless of the industry they are in, the system that they use, or the standards that their partners require.

    As some of you may have noticed, Microsoft Dynamics NAV 2013 shipped without Commerce Gateway. We have explored a number of different options for enabling Commerce Gateway. This blog post describes the recommended upgrade path for users of Commerce Gateway to make their solution compatible with Microsoft Dynamics NAV 2013.

    We are currently working on a sample application that will demonstrate how to upgrade the Commerce Gateway solution. The sample will show how you should set up the connection between Microsoft BizTalk and Microsoft Dynamics NAV using a web service. The sample will be shipped through the hotfix process, after it has been through testing. For now, we expect to release the sample at the end of March.

    New customers that need Commerce Gateway will have to upgrade their solutions from Microsoft Dynamics NAV 2009 to Microsoft Dynamics NAV 2013. For more information, see Upgrading to Microsoft Dynamics NAV 2013.

    Commerce Gateway is still included in the license as part of the product and can be purchased as normal.

    Architectural changes

    In architectural terms, the Commerce Gateway solution consists of an application part, a communication part, and a BizTalk part. The communication part is the part that requires the most changes to be able to run with Microsoft Dynamics NAV 2013. We recommend that you change the communication part to use a web service connection instead of using the Request Client and the Request Server. For this to work, it is also required that you make a few changes to the Microsoft BizTalk configuration. There are minor changes to the application part.

    The main reason changes to Commerce Gateway were required for it to work on Microsoft Dynamics NAV 2013 are the architectural changes that were introduced with this version, such as the 64-bit Microsoft Dynamics NAV Server, as well as the removal of COM support on the server. Both changes require a change in the Commerce Gateway implementation, since it relies on a 32-bit COM implementation for the Request Server and the Request Client.

    Summary of recommended changes

    1. Upgrade application code to Microsoft Dynamics NAV 2013. The application code is impacted by the removal of support for forms.
    2. Change the connection between the Microsoft BizTalk server and Microsoft Dynamics NAV 2013 to use a new web service, which will be defined in the sample. Changing your solution to use web services will simplify the Microsoft Dynamics NAV 2013 installation, as you will no longer be required to use the Commerce Gateway Request server and the Commerce Gateway Request Client.
    3. The Microsoft Dynamics NAV 2013 architecture does not allow the use of automation on the server. Consequently, we have changed five objects to use the .NET Framework XML Document Object Model (DOM). You will have to upgrade your solution to merge in these changes.
    4. Change the connection setup on the Microsoft BizTalk Server to use the web service. You will need to create a new Send port and to reconfigure the orchestrations.

    All of the above changes will be described and implemented in the code sample that will ship at the end of March.

     

    Rikke Lassen

    Senior Program Manager

Page 2 of 44 (650 items) 12345»