Copying Objects from one NAV Database to another

Today’s topic is by request from a reader of our blog, who wanted to know how to copy objects from one NAV database to another. An example of when you’d do this is while moving customizations from the testing or development database to the live database.

The process itself is very straightforward, although it will appear lengthy because of all the detail I’ll include with each step along the way.

But there are a few things that be mindful of, best practices if you will, and I want to address those first:

  1. Always make a backup of the objects in the Live Database that you will be updating (replacing) – this process is outlined in more detail later in this post.
  2. It is a good idea to ask all the users to log out of NAV before importing / replacing objects. I strongly advise it. Especially if the object you will be updating is a commonly used object (like an object related to Sales, Purchases, Customers, Vendors, etc.) Are your users out of NAV yet? Good. Let’s continue. 🙂
  3. If there are a lot of objects that are being updated, it may be a good idea to make a complete backup of the database. Better safe than sorry.
  4. And since this post is not aimed at developers, we’ll assume that both databases are from the same version of NAV and are basically identical copies of each other (except for these fresh modifications that you have made and want to copy over). 

One last thing before I continue: Please understand that you are attempting this at your own risk. There is no express or implied warranty here, and I cannot be held responsible if something goes wrong and you lose data, or the database becomes corrupted or unusable. It is your responsibility to make a full backup of the database first before attempting this.

Okay, now we are ready to talk about how to copy objects!

To keep things simple, we’ll call the database that you are copying from the Source database; and we’ll call the database you are copying to the Destination database. All the steps below are performed from the NAV Classic Client.

Steps for Extracting the changed objects from the Source database:

  1. Connect / log in to the Source database, and open the Object Designer (listed under the Tools menu; you can also get to it by pressing Shift + F12)
  2. Find and select the object you want to copy: Let’s assume you would like to copy Page 21, which is the Customer Card. Click on Page from the list of Object types. The click in the ID column and type in 21 (or navigate to that page number). When you click once on the row that shows Page 21, an arrow will appear in the white box to the left. This confirms that our object is selected.
  3. Click on File > Export. (If you are wondering how come you never saw the Export and Import menu items before, it’s because they only appear when the Object Designer window is open and in focus).
  4. The Export Objects window will appear. Make sure the Save as type: is set to “Dynamics NAV Object Format (*.fob)” and type in the desired name for the file and select a location to save to. Click Save.
    1. In case you are wondering why we selected *.fob and not *.txt as the file format, it is because there are limitations in place that prevent objects from being exported in text format without a developer’s license.
  5. The file is now saved / exported and ready to import into the Destination database.

What if you have more than one object that you would like to copy at a time?

In step 2 above, I described how to find and select one object. If the additional object(s) appear immediately preceding or following the first selected object, you can use the Shift+Up key or Shift+Down key combination to select multiple objects.

But if the objects are all over the place, we use the Mark functionality. After finding each desired object, select it by clicking on it, then go to Edit > Toggle Mark (or press Ctrl+F1). Do this for each object you want to export. Each marked object appears with a black diamond icon in the first column.

Once all the desired objects are marked, go to View > Marked Only (or press Alt+V, then M). This will show you only the objects that you marked. If you marked different types of objects (some Tables, some Pages, some Reports), make sure the Object type which appears on the left hand side of the Object Designer window is set to All.

Now, you must select all of these objects before you can export them. Go to Edit > Select All (or press Ctrl+A). All the objects will now be highlighted in the Object Designer window.

From here, you can continue the directions from step 3 as shown above.

Okay, now that we are done extracting objects from the Source database, we’re going import them into the Destination database.

Steps for Importing the Objects (.FOB) file into the Destination database:

  1. Connect / log in to the Source database, and open the Object Designer (listed under the Tools menu; you can also get to it by pressing Shift + F12)
  2. IMPORTANT: Select and export a copy of the objects in the Destination database which are about to be replaced. You will need this in case something goes wrong or you want to revert back to the way things were.
    1. Follow step 2 and step 3 as previously described in Steps for Extracting the changed objects from the Source database.
    2. In the Export Objects window, save this .FOB file with a different name. I like to call this file “PreChangeObjects-MMDDYY-HHMM.fob” where MMDDYY are two digits each of the month, date, and year, and HHMM are 2 digits of hour and minute (in 24 hour format,  with leading 0 when needed).
  3. Click on File > Import. Browse and locate the .fob file that you just extracted from the Source database. Click Open.
  4. A window should pop up with a message similar to this, which asks whether or not you wish to open the Import Worksheet:
  5. I always recommend that you look at the Import Worksheet before proceeding with the import. So if you see the message above, click NO to open the Import Worksheet.
    1. If you were to click Yes to this message, NAV would decide what to do with the objects (Replace, Merge, or Skip; or Create if you were bringing in an object that doesn’t exist in the Destination database.
    2. Important Note: DON’T get in the habit of just pressing NO without reading the message first. The emphasis is not on Yes or No; the emphasis on clicking the button that will open the Import Worksheet.
      I say this because in some cases (which should not happen in the situation we’re describing here) you may get a warning that states the objects could not be imported “because there are objects already in the database with conflicting versions.” In this case, you need to press OK to open the 
      Import Worksheet or Cancel to stop the import. 
  6. In the Import Worksheet window, you will see a full list of objects that you are attempting to import. In the Action column, you will see the default action suggested by NAV. Regardless of what the default section is, change the value in the Action column to Replace. Instead of doing this for each object one-by-one, an easier way to do this is by clicking the Replace All button that appears near the bottom of the window.
    1. At the end of this blog post, I’ve explained in a little more detail why we ignore NAV’s default suggestion.
    2. If the object you are attempting to import is new and does not exist in the Destination database, your only options are Create and Skip. Assuming you want to import it, you will have to select Create.
    3. If you select Skip for any object, that particular object will NOT be imported.
  7. Click OK, and NAV will import the objects. Once the import is completed, it will display a summary of the import (how many objects were created, replaced, skipped, etc.). Click OK again.
  8. We’re almost done. Although importing an .FOB file imports the objects in “compiled” status, it is recommended that you still compile them after import.
    1. Open the Object Designer window.
    2. To compile, select all the objects that you have imported (follow the steps shown in this post to select multiple objects), then go to Tools > Compile (or press the F11 key).
    3. When selecting the objects to compile, REMEMBER to select the appropriate Object type before selecting the Object number. You can have the same Object number across different Object types, so it is easy to pick Table 18 instead of Page 18 (for example) if you’re not paying attention.
    4. Unless there there is an error, you will not see any message to indicate that NAV has finished compiling the objects. You can tell whether it is compiling or done by whether you are seeing the hourglass (or whatever the equivalent round thingi is that appears in Windows Vista and Windows 7 when the system is busy) or a regular mouse pointer. Also, while it is compiling, NAV is unresponsive so you cannot do anything else in that NAV client.

That’s it! You’re done! If you need to revert back to the old objects, simply follow the steps above to import the “pre-change objects.”

Final thoughts:

– If you have a developer’s license and for some reason you exported the file in .txt format, when you import this .txt file in the Destination database, it will overwrite the existing objects without asking for confirmation. The import objects will not be compiled, so you will not be able to run or use them until you’ve compiled them first. See the instructions previously described in this blog post on how to compile all the imported objects.

– Sometimes, you just have too many hands in the pot (read: too many developers working on a bunch of different projects for the same database at the same time) and you may find that more than one developer is working on the same object. And if these developers aren’t communicating with each other, it could cause a lot of frustration or worse.

For example, if someone is modifying an object in the Live database (which isn’t recommended in the first place) while you are modifying the same object, guess what happens when you import your object into the Live database and replace the one that was already there? Yep – you overwrote the other developer’s modification. A friend of mine calls that “one step forward, two steps back.

Before someone responds and says: hey, what if I just select one of the Merge options in the Import Worksheet’s Action column instead of Replace when importing the object? To you I say: If it were a person, I wouldn’t trust the built-in Merge functionality to take my trash out on Monday mornings. 🙂 Perhaps a little harsh, but honestly, I wouldn’t trust it to make decisions for me – and I am in good company on this one. I use it in very rare situations.

When I have conflicting versions of objects that need to be merged (or when I need to merge an ISV’s code into a modified object), I export the objects from both databases in .txt format, and then use a text editing tool that lets me compare two text files and spot the differences (there are a lot of such utilities out there. Feel free to e-mail me if you need a recommendation).

There are also some nifty little NAV specific tools out there aimed at developers – one specific utility worth mentioning is MergeTool ( by Per Mogensen. Quite generously, he has made the tool available at no charge to anyone who has a developer’s license. He also has other great utilities that are worth checking out. And no, he has not paid for or asked for this endorsement. In fact, he isn’t aware that I’m recommending it. For all I know, he may not even know about this blog.

Note: Happy birthday Mom! And Happy birthday to my “partner in crime NAV”, Krystal!

Leave a Reply