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:
The attached document contains Michael's recommendations, including the following options and parameters:
These postings are provided "AS IS" with no warranties and confers no rights. You assume all risk for your use.
You can find any page, report, or Departments view in your installation by using the Search box to the right of the Address box. In this way you reduce the amount of time you spend searching.
When you start typing characters in the Search box, a drop-down list shows page and report names containing the character(s) you type. The drop-down list changes as you type more characters, and you can select the correct page or report from the list when it is displayed. The second column in the drop-down list shows the navigation paths to the found pages and reports. You can select the path in the second column to navigate to the Departments page where the page or report exists.
Here are the detailed steps for searching for pages, reports, and Departments views from the Role Center.
1. In the Search field in the top right corner, type "sales".
2. Continue typing with "invoices".
The second column in the drop-down list shows the navigation paths to the found pages and reports and you can select the path to navigate to the Departments page where the page or report exists.
3. Select either the page or report in the first column of the search results or the path in the second column of the search results.
For more information about usability and the RoleTailored client, see the blog post Useful, Usable, and Desirable.
I have collected few tips maybe could be used in NAV 2009 developing.Don't claim me too much if this looks to easy... :)
With the release of Dynamics NAV 2009 R2 we have spent some time trying to understand the issues related to hosting the product. Based on these discussions we have added some things to the R2 release and will be adding things to the next release as well to accommodate hosting of NAV even further. The features we have added related to hosting the product are:
To begin with let us have a look at the environment we are adding to the mix with these features.
In current releases this would be possible by adding a VPN connection to the mix with the performance overhead and administrative cost that it adds.
To mitigate a possible man in the middle attack we have added the ability to add a certificate on the server side of the setup. This helps ensure that the server to which the client is connecting is actually the one that it should be connecting to.
As most hosting scenarios require any client to login to a domain that is run by the hosting company we have added the ability to show a login dialog when opening the RoleTailored client to allow a user of NAV to easily provide those credentials to the remote site in a secure fashion. This happens over an encrypted channel to the SSL-verified server in the other end.
After the connection is established the communication between the RoleTailored client and the server is also encrypted to ensure that if someone is listening in on the communication it would be garbled while being transmitted over the internet.
The natural question to ask is then "what does this mean in terms of performance?" We have spent quite a while looking into that to be able to come up with some guidelines about which requirements should be put upon the network connectivity between the hosting site and the customer site.
We have focused our tests around two factors - latency and bandwidth. The way we have tested this is in a simulated environment where we were able to throttle both bandwidth and latency to be able to simulate different types of connectivity. The tests we performed were 10 concurrent users posting 10 one-line sales orders in an automated fashion through the User Interface of the RoleTailored client. An important note here is that this type of measurement is not entirely realistic as the actual entering of the Sales Orders are fast to the point that the UI doesn't render before the Post button is pressed. This also means that if this is the "benchmark load" any real life load with similar operations will be slower.
We tested bandwidths ranging from a 10/1 mbit line up to a 300/300 mbit line which would be somewhat similar to a LAN. Bandwidths are setup so a 10/1 line would be 10 mbit download speed to the client site and 1 mbit upload speed from the client site.
Latencies were tested between 0 ms to 600 ms, which is ranging between a fast LAN connection to a slow ADSL connection or even a fast satellite connection, which would be between 500-1000 ms.
The graph below shows the response times as the red line, the maximum kilobytes received per second as well as the average kilobytes received per second, the maximum kilobytes sent per second and the average kilobytes sent per second.
The x-axis signifies the round-trip time added to the connection in milliseconds.
Looking at the graph it shows that latency linearly impacts the response time for obvious reasons. It also shows that a higher latency impacts the ability to utilize the available bandwidth and that the sweet spot/elbow is between a latency of 100ms and 150ms.
The graph for the bandwidth scenario is somewhat less complicated. It shows the bandwidth per user on the x-axis and the response time for the 10 sales orders on the y-axis. Note that the bandwidth per user means that 5/1 is equivalent to a 50/10 mbit connection. 2/0,5 is a 20/5 mbit connection.
The graph shows that the elbow is somewhere between 1,5/0,3 mbit per user or a 15/3 mbit line and 2/0,1 mbit per user or a 20/1 mbit line. Additional studies also show that the determining factor for these connections are the upload speed rather than the download speed and that the elbow is between 0,1 and 0,3 mbit per user for the tested scenarios.
As this is targeted towards limited bandwidth scenarios it is worth noting that for any type of connection it will be possible for a single session to use it all if transferring a large file or even running a large report.
Together with this release we will provide documentation to help configure the network infrastructure that is needed for the RoleTailored client to be able to communicate with the NAV Server over the WAN.
Recently Microsoft hosted a Hot Topic Session called "Microsoft Dynamics NAV 2009 R2 Hot Topic: RoleTailored Client for remote and roaming users". A recorded version of the session can be seen at the Parther Learning Center.
- Claus Busk Andersen
You can add and delete buttons and lists in the Navigation Pane.
1. In the top right corner of the Role Center, click Customize button.
2. Click Customize Navigation Pane.
3. In the Customize Navigation Pane window, click New to create a new button.
4. Type a name for the new button.
5. Choose an icon.
6. Click OK.
7. Use Move Up, Move Down, and Rename to edit the position and name of the new button.
8. Click Add to add new lists.
9. Browse to the list you want to add.
10. Click OK.
11. Repeat steps 8 through 10 for all the lists you want to add.
12. Use Move Up and Move Down to edit the position of the lists.
13. Use Move To and Copy To to move lists from one navigation pane button to another.
14. Click OK.
15. Click Yes to restart the Role Tailored Client.
After restart, the changes will be applied to the Navigation Pane.
For more information about usability and the RoleTailored client, see the blog post Useful, Usable, and Desirable.
Sometime ago I have promised to publish the numbers used in NAV for the data types. These numbers are used all over the system, but are more visible when encoding record links (please refer to my post about encoding record links). This list contains the data types that are available in Tables in NAV 2009 SP1.
(0x2E ‘+’ 0)
(0x2E ‘+’ 1)
(0x2E ‘+’ 22)
(0x13 ‘+’ 125)
Internally some types are “extensions” of other types, and therefore are composed as a base type and subtype ID. As an example Time (2E ‘+’ 1) is a “subtype” of Date (2E ‘+’ 0).
In order for the RTC (Role Tailored Client) to export to a shared location using Constrained Delegation, you need to setup delegation for the account that is running the NST service to the machine that is hosting the share. Here are the instructions on setting up delegation:
1. Open the User that is running in NAV Server Service in AD (Active Directory) and go to the Delegation Tab
2. Click on 'Add'
3. Select 'Users or Computers'
4. Enter in the name of the machine that is hosting the Shared Folder
5. Click 'Check Names' and now it should show an underline below the servername
6. Click 'OK'
7. Now you should see a list of Services for this machine that contains the shared folder
8. Click on the Service called 'cifs'
9. Click 'OK'
10. The end result should now look like this:
Nick Haman, North America Escalation Engineer
In fields that take input, such as Sell-to-Customer No., Location Code, or Address, as you start entering characters, a drop-down list shows possible field values that match the characters you have typed. Typcally, Microsoft Dynamics NAV sets the default filter to the number value in number fields such as Customer No. and to the text value in fields such as Address.
But you can change the default field you use as a filter. In this example, you can change the filter from No. to Name.
Now, as you type in the Sell-to Customer No. field, the filter is set to look in the Name column rather than the No. column.
I am happy to announce that due to popular demand, we have recently posted a whitepaper covering SEPA on PartnerSource and CustomerSource.
To give you a little bit of background, in 2002, key European banks decided to create a standardized payment strategy called the Single Euro Payments Area or (SEPA) to allow payments to easily transfer electronically. SEPA is the framework that manages the necessary infrastructure and standards for the euro. SEPA actually consists of two different core concepts: credit transfers and direct debits. SEPA Credit Transfers (SCT) are a payment that a payer initiates. The payer must send payment instructions to a bank and then the bank transfers the funds from the payer's to the beneficiary's account. These are transactions between two accounts held by financial institutions in the European Economic Area (EEA). SCT are currently supported in the following localized versions of Microsoft Dynamics NAV.
SEPA Credit Transfers
Released in Microsoft Dynamics NAV version
4.0 SP3, 5.0 SP1, 6.0 SP1
5.0 SP1, 6.0 SP1
Development is currently underway for SEPA Credit Transfer XML payment format for the following countries.
Expected release date
(This list is subject to change.)
SEPA Direct Debits (SDD) is the other part of SEPA. SDD are different from SCT because they are initiated by a creditor. We currently do not have any concrete plans on releasing support for SDD but are keeping up to date with business, market, and legal requirements and will continue to support direct debits in countries where the functionality already exists as a localization of Microsoft Dynamics NAV.
For those of you who would like to know more about SEPA and how it affects our customers and products, please take a look at the whitepaper here:
- Selena Laccinole Jensen