3 Easy Methods to move company data between NAV databases


If there is something that changes in NAV every few releases, is how we backup and restore data (be that full backup, application data, companies data) between NAV databases.

Recently I was asked how is this done in NAV 2016.

The answer is simple and is applicable to both NAV 2015 and NAV 2016:

  • with 2 powershell cmdlets
  • via Pages 9901 (for Export) and Page 9900 (for Import)
  • using C/AL functions EXPORTDATA/IMPORTDATA.

Let’s assume the following case. A bug was reported by a customer. You want to have access to his production environment, but many times that’s not possible. One way is to do a SQL backup of customer’s database. That assumes you will have at least backup rights on their database server. Many times that’s not possible. But you probably have access to NAV.

Let’s try to export company data with powershell cmdlets:

  • Launch Dynamics 2016 Administration Shell
  • Run the following cmdlet:NAV-ExportData
    • DatabaseName : look in the NAV Administration console for the database name associated with your instance
    • FilePath: it is expected a file with extension “navdata”
  • Copy navdata file onto your local machine and run the following cmdlet to restore the company data in your other environment (be that development, or QA …)NAV-ImportData
    • Similarly to the previous step, DatabaseName can be extracted from the NAV Administration console and FilePath is a local file with a “navdata” extension
    • The cmdlet is confirming that we want to overwrite the company “…” on the local server “.\ServerName”
    • After confirmation of the overwrite, the importing starts, but we get an error. The cmdlet reports that there is a difference in a table definition. In the example above, on the destination database, one of the tables had a few new fields, just because the destination environment was a development copy of customer’s database.
    • To get around this error you need to have similar objects on the destination and the source. So I saved the latest changes on the target database (exported to a fob) calling it LatestChanges.fob. Then I sync’d objects from customer production with target database. I re-run again Import-NAVData and this time it run without issues.
    • ImportSuccesful
    • After a succesful import of company data you can restore your code from LatestChanges.fob
  • The easiest way though, to restore a company data, is to use Page 9901 (for Export)on the Source and Page 9900 (for Import) on the Target.

To export/import data via C/AL code check EXPORTDATA and IMPORTDATA functions:


For a sample of how to use these 2 functions, check the code in pages 9900, 9901 in W1.

Original post here.



NAV Upgrade Notes – First essential step for a successful NAV upgrade


The first step in my last NAV upgrade was to back up customized tables. Although having database backups throughout your upgrade process is a no brainer, my focus in this post is backing up locally tables that contain non-standard fields. Having the heavy customized tables readily available in the same database, somewhere in the range 50000-99999 it can prove useful.

For example, let’s say the table 21 Customer Ledger Entry in my customer NAV 2009 database has a few non-standard fields in the range 50k or some other range. My plan is to have an exact copy of this table with ID 50000, table that I can carry forward until the upgrade process reaches NAV 2017.

Having the original data allows me to:

  •  re-construct any field that might have gotten lost or overriden during the upgrade (through a Forced sync without an upgrade codeunit or some other faulty process) or
  • perform conversion validation like comparing the balance for each customer in the original table(now saved in the 50k range) with the value from the upgraded table.

To backup the table I start with opening the original table (21), copy all fields, create a new table in the 50k range (60007) and paste all the fields. In the new table we don’t need any business rules, therefore we can select all code lines and delete them.

I would do the same for all tables whose data I want to back up.

If your backup set includes like mine, hundreds of tables, I would create a new table(50000) where I am planning to keep all original-backed up table pairs. For example, I can have pairs like table 21 – table 60007 in the new table:

List Of Tables

Next we need to populate the new table 60007 with original data.

Create a new codeunit and traverse table 50000. For each row execute the following function:


This method copies the value of “Normal” fields from the source table(21) into each correspondent field from target table(60007).