Microsoft Dynamics NAV

Team Blog

January, 2008

  • Microsoft Dynamics NAV Team Blog

    How to Re-apply a Language Pack when deploying the Outlook Integration Update for Microsoft Dynamics NAV 5.0


    The language module file helps you to save the existing text messages and captions, and propagate them to the Outlook Integration Update objects.
    How to apply the language module file to the C/AL objects provided with the Outlook Integration Update:

    1. Before you import the objects you received with the Outlook Synchronization Update package, open your localized version of the database.
    2. Select the objects which are going to be replaced by the Outlook Synchronization Update objects (18 objects should be selected).
    3. Go to Tools -> Language Module -> Export.
    4. Specify a valid path and name for the language module file which will be created based on your current objects.
    5. Select the language which corresponds to your country and click OK.
    6. Microsoft Dynamics NAV has now created an *.flm file at the specified location. You can open it with any text editor (for example Notepad) and verify that it contains text messages and captions collected from your localized objects.
    7. Import and compile the C/AL objects included in the Outlook Synchronization Update package.
    8. Select all the objects you have just imported (you can apply a filter to the Version List field and use value "NAVW15.00.PS29299" for the filtering.) 
    9. Go to Tools -> Language Module -> Import.
    10. Navigate to the *.flm file created on step 6 and click OPEN to import it. Click OK to confirm your choice.
    11. Verify that the objects contain captions and text constants in your language. 

    Mtoo Norrild
    Program Manager

  • Microsoft Dynamics NAV Team Blog

    Simon Goes to Work: Developing Solutions for Microsoft Dynamics NAV "6.0"


    The whitepaper Whats New Developing Solutions for Microsoft Dynamics NAV "6.0" was released late last year and gives an overview of some of the new features and how to access those new features specific to NAV 6.0.

    The paper has been under development for nearly as long as the NAV 6.0 project itself.   At the beginning of the Corsica project, two events occurred that drove its creation. The first was the persona model was being driven as a toolset across development teams – this is exactly the same persona model you can find here and is a fantastic tool for unifying terminology and understanding of which users we’re targeting on our feature teams.  Until we had the persona model, we used use cases that merely stated “an experienced developer blah blah blah”, and now we had Simon, Isaac and Mort to target our features to.

    The second event was that as the development team that created the C/AL to .NET compiler was formed and there was a request from the Testers in the team to diagram and specify how developers worked.  As hard as I could, I was not able to argue that everybody already knows how developers work. The Testers insisted that if everyone knew how developers worked then it should be easy to capture it in a simplistic way.

    I’m glad they argued.

    So I began writing a document called Simon Goes to Work.  Simon in honour of the persona closest to a classical NAV consultant/developer .  In writing the use cases and drawing the diagrams for how developers move from code to compilation to deployment and from setup/installation to upgrades and from backups and restores, we identified a host of issues.  Without going into details, it gave us a handle on a specific special scenario that we could theory-test against our design.   It was the cause for some redesign and is generally considered a good thing that we did it.

    But wait … there’s more.

    After the development teams had been plugging away at this project for some time, we began to get questions from other internal MS groups.  Questions about the features and how they should be described and positioned (i.e., how to sell them to our partner channel/why we consider them valuable).  This is really something that happens on the tail end of projects – documenting the value of the features that we set out at the beginning of the project to achieve.  At that point, it was far simpler to share the Simon document with them to answer the questions about how things worked.

    In the end, we got lots of feedback from the internal teams with questions and we elaborated more and more to the Simon document until the realization occurred that this document not only answered a lot of questions for internal Microsoft Team Members, but it might also be a good read in preparing people for what is to come on NAV 6.0.  Naturally you wouldn’t expect Microsoft standard naming conventions to be supportive of a whitepaper called Simon Goes to Work so after enough committees and focus groups, it eventually grew the name it has today.

    We haven’t really written a paper like this before but it does fill a place answering some common questions about NAV 6.0.  I hope you get a chance to look it over and hope it helps understanding another piece of the 6.0 puzzle.

    Download What's New - Developing Solutions for Microsoft Dynamics NAV "6.0" (PartnerSource access required)

    - Stuart Glasson

  • Microsoft Dynamics NAV Team Blog

    Outlook Integration update for Microsoft Dynamics NAV 5.0


    I am pleased to announce Outlook Integration Update for Microsoft Dynamics NAV 5.0. This update is now available for you to download at PartnerSource  login credentials are required.

    The Outlook Integration update rollup corrects the issues that are described in KB article number 945879. Apply the Outlook Integration update, following recommendations in the Installation & Setup Whitepaper included in the package, only to systems that are experiencing these specific problems. This update applies to Microsoft Dynamics NAV for all countries and all language locales.

    From the link above we have released:

    • Outlook Add in installation program + set of corrected C/AL objects;
    • Supplementary installation program, to deploy corrected dlls used by the C/AL objects;
    • Installation & Setup Whitepaper.

    Mtoo Norrild
    Program Manager

  • Microsoft Dynamics NAV Team Blog

    Correcting Acquisition Cost Errors in Dynamics NAV


    One of the top customer questions we receive in the Fixed Assets area is about correcting Acquisition Cost Errors.

    For example, an acquisition cost has by mistake been posted the 1st of May 2002 instead of the 1st of May 2001. The mistake is corrected by removing the entry with the function Cancel Entries and then posting the acquisition with the correct date. The function Cancel Entries is on the FA Ledger Entries form.

    It would be inappropriate to use the function Reverse Transactions. The function Cancel Entries removes the entries from the FA Ledger Entries form and transfers them to the form FA Error Ledger Entries, whereas the function Reverse Transactions posts an entry with the opposite sign. Therefore, the batch job Calculate Depreciation cannot depreciate the fixed asset until the 1st of May 2002 if the function Reverse Transactions is used.

    Note that Cancel Entries is a function specifically made for the fixed asset functional area whereas Reverse Transactions is a more general function for all general ledger postings.

    - Henrik Sonne.

  • Microsoft Dynamics NAV Team Blog

    Convergence 2008 - More NAV Sessions Than Ever!


    Convergence 2008 is on the horizon - March 11-14 in Orlando, Florida.

    The preliminary agenda only showed a few Dynamics NAV sessions, but has recently been updated revealing the full glory of NAV-iness at the Conference.  This year's Convergence will have more sessions than ever before: currently 3 partner sessions, 1 customer general session, 28 breakouts and 10 interactive discussion sessions.  See the session catalog for details.

    Register here

    (Early Bird Registration finishes today, so move fast if you want to take advantage of that.)

    Convergence is a great event for anyone involved with Dynamics products.  We hope to see you in Orlando!

    - Ilana Smith

  • Microsoft Dynamics NAV Team Blog

    Overview of updates for SQL Server 2005 SP2


    This post has the following three purposes:

    1. Give awareness that there are updates available for SQL Server 2005 SP2
    2. Give an overview of what the available updates mean in relation to running Microsoft Dynamics NAV on SQL Server 2005
    3. Help deciding whether a customer who runs Microsoft Dynamics NAV on SQL Server 2005 should install any of these updates (and which one) 


    The base version of SQL Server 2005 SP2 is build 9.00.3042.00 (build 3042). Since this build, a number of updates have been released, some of them containing important corrections.

    To find the build of SQL Server 2005, run this script from SQL Server management Studio:

    SELECT @@Version

    Q:  Should I install a SQL Update?
    Especially cumulative update 1 (build 3161) contains some important corrections (see details below). So if your SQL Server has a build number lower than 3161, then I would recommend that you update it when convenient - even if you have not been affected by any of the issues described here. If SQL Server is build 3161 or higher, then I would recommend to install the update as part of your normal update practise, unless you experience any of the symptoms described here.

    Q:  If I install a SQL update, which one should I install?

    All the SQL updates are cumulative and contain all previous updates. So whenever you do install an update, you might as well install the latest one. The latest update for SQL 2005 (January 2008) is "Cumulative update package 5 for SQL Server 2005 Service Pack 2 (KB 943656)".

    Plpease note: Any time you experience a problem, you should search / Partnersource, and/or raise a support request. This post only describes a small part of potential issues, and only issues that are directly related to NAV.

    Further details:

    The following section is a description of the problems we have seen on NAV installations, which have been corrected in SQL updates:


    1) SQL Serv er slows down
    KB 933564 / SQL Hotfix bug number 50000945:

    FIX: A gradual increase in memory consumption for the USERSTORE_TOKENPERM cache store occurs in SQL Server 2005

    This article mentions that "This problem can lead to an increase in memory consumption by the USERSTORE_TOKENPERM cache store.". It means that the "cache store" can end up consuming all available memory, which will slow down SQL Server. Restarting SQL Server will clear out the cache, and it will run fine again until the "cache store" fills up again. The typical symptom is that SQL Server is running OK for a while, but then for no apparent reason slows down. Users experience very slow response on both read and write operations. This problem has especially been experienced at systems with large amount of memory (12-16GB +).

    The correction for this was included in cumulative update 1.


    2) Another user has changed ... - errors from NAV 

    KB 930775 / SQL Hotfix bug number50000695:

    FIX: Error message when you try to retrieve rows from a cursor that uses the OPTION (RECOMPILE) query hint in SQL Server 2005: "Could not complete cursor operation because the table schema changed after the cursor was declared"

    When using the $ndo$dbconfig-table to add OPTION(RECOMPILE) to NAV queries (documented elsewhere), NAV would throw this error when browsing forms:

    "Another user has changed the definition of the [xyz] table after the activity was started.

    Start again."

    This SQL correction corrected that problem. This correction is also included in cumulative update 1.


    3)  Some queries ran faster  on SQL2000 than they do on SQL2005

    KB 942659 / SQL Hotfix bug number50001716:

    FIX: The query performance is slower when you run the query in SQL Server 2005 than when you run the query in SQL Server 2000

    This problem was experienced by a very few NAV customers after they upgraded from SQL2000 to SQL2005. The symptoms were: When changing a field filter (F7) on "Name" in a contact list, the response would take a couple of seconds. The same actions would give instant response on SQL2000. This problem did not cause drastic table scans, "only" 3-5.000 more reads than SQL 2000 would have done. But of course, in a multi user system this would cause a lot of unnecessary reads.

    The correction was to implement a new trace flag 4119. Enabling this trace flag will set SQL2005's behaviour to that of SQL2000 for these specific queries. This trace flag is further documented in this post:
    New trace flag in Update 4 for SQL 2005 SP2

    This correction is included in cumulative update 4.



    Finally, refer to this list for an overview of some of the updates that are available for SQL2005:

    The SQL Server 2005 builds that were released after SQL Server 2005 Service Pack 2 was released


    Lars Lohndorf-Larsen (Lohndorf)

    Escalation Engineer

  • Microsoft Dynamics NAV Team Blog

    Simple query to check the recent performance history


    The query described in this blog is a variant of a query described in KB 935395 on Partnersource (login required). While this KB article described issues specific to SQL Servers plan-cache, the query has proved to be very useful in general performance troubleshooting of SQL installations.

    The query is using Dynamic Management Views (DMVs), which were introduced in SQL Server 2005. So it will not work for SQL 2000.

    It gives you an immediate view of the top 30 plans currently in cache, ordered by number of reads (or writes with a small change). So it gives you a view of the queries that are most likely to cause the most performance problems. In this way, it does what you would have otherwise had to use SQL Profiler for, but without the overhead of SQL Profiler, or the need to spend many hours browsing through 1000s of lines of details in Profiler traces.

    So, here is the query:

        SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
        ((CASE statement_end_offset
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset END
                - qs.statement_start_offset)/2) + 1) as statement_text,
      when execution_count = 0 then null
      else total_logical_reads/execution_count
       end as avg_logical_reads,
      when execution_count = 0 then null
      else total_logical_writes/execution_count
       end as avg_logical_writes,
    FROM sys.dm_exec_query_stats as qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as st
    ORDER BY max_logical_reads DESC --change here to sort by max_logical_writes

    The query is read-only. It does not cause any locks or any noticeable overhead to SQL Server. So I would recommend anyone with a SQL 2005 installation to try to run it. This is what it shows:

    Every time a query is sent to SQL Server, SQL Server makes a query-plan for that query. It then caches this plan to re-use it for identical queries. This plan-cache also collects statistics about how efficiently each query-plan was run. This query looks into the plan-cache and retrieves the plans, with the one causing the most reads at the top. It returns (among other things) the following information:

    text and statement_text:
    This shows you the query that this plan is being used for. Remember, the same plan can be used again and again for identical queries.

    Shows you how many times the plan was used. If this shows 1, the plan may have been for a one-off query, and it may not be relevant to investigate it further. If it shows a high count, then the plan is for a common query, and you may want to investigate further where this query came from.

    After this, there are a number of self-describing columns, showing you statistics about number of reads and writes for each plan.

    The query can easily be changed, to order by writes instead of reads - just change the ORDER BY clause in the last line.


    The query is a very simple tool to get some very useful information out of SQL Server. In some cases, it can identify the same problems as SQL Profiler, but in a much simpler and quicker way.
    The query is completely risk-free, and can often show some very useful information.

    As mentioned, the query will not work for SQL Server 2000 (or earlier versions).
    SQL Server's plan-cache is very dynamic, and it changes many times every hour. So the results of the query can easily differ from one hour to the next. So it will only give you a snapshot of current cache - not full statistics since SQL Server was first started.

    - Lohndorf

Page 1 of 1 (7 items)