In earlier versions of Microsoft Dynamics NAV, you could move or copy all or part of the data in a database by using the Microsoft Dynamics NAV backup functionality. In Microsoft Dynamics NAV 2013 R2, the support for the .fbk files was removed, but with Cumulative Update 8 for Microsoft Dynamics NAV 2013 R2, we introduce Windows PowerShell cmdlets so you can export data from a Microsoft Dynamics NAV database and import it into another Microsoft Dynamics NAV database. You can also export and import data in the Microsoft Dynamics NAV Windows client.
You can export and import a single company or all companies in a database, and you can export and import other types of data such as global data, application data, and application objects. As part of Cumulative Update 8, we include a whitepaper that provides examples of the types of data and how to export and import data using Windows PowerShell cmdlets as well as in the Microsoft Dynamics NAV Windows client.
When you export data from a Microsoft Dynamics NAV database, the data is stored in a file with the extension .navdata, which is a new file format that is proprietary to Microsoft Dynamics NAV data. You cannot edit the .navdata files in other tools.
The data that you export is not deleted from the original database. So that means that you can use the functionality to essentially take a copy of your customer’s live data, leave them to continue working, while you import the data into an offline database back at your office for further debugging or other investigation. You can also use the .navdata files to move data to a new database, such as moving a company to a new database when you want to deprecate a database, for example.
To export or import data, in the Search box, enter Data File, and then choose the related link.
To export data, you specify the type of data that you want to export, and when you choose the OK button, you specify where you want to save the file.
To import data, you specify the .navdata file to import data from, but you can't import an application if the .navdata file contains an application. This is because you can't overwrite the application that is currently open in the Microsoft Dynamics NAV Windows client. So the window has one less type of data that you can choose to import:
If you want to import an application into a Microsoft Dynamics NAV database, you must use the Import-NAVData Windows PowerShell cmdlet.
The following table describes the Windows PowerShell cmdlets that are new in Microsoft Dynamics NAV 2013 R2 Cumulative Update 8.
Exports data from a Microsoft Dynamics NAV database. You can export company-specific data, and you can choose to include global data, application data, or application objects.
Imports data into a Microsoft Dynamics NAV database from a file. You can import all data in the file, or you can choose to include specific companies, global data, application data, or application objects.
You can only import an application into an empty database.
Gets information from a file that has been exported from a Microsoft Dynamics NAV database.
The extracted information includes the types of data that the file contains and any company names.
The cmdlets take different parameter sets depending on how you connect to the database that you want to export data from or import data into. You can access the database through the Microsoft Dynamics NAV Server instance, or you can access the database directly as described in the following table.
Through the Microsoft Dynamics NAV Server instance.
Use parameter sets that include –ServerInstance when the database that you want to access is mounted against a Microsoft Dynamics NAV Server instance.
The user account for the Microsoft Dynamics NAV Server instance must have access to write to the location that is specified by the –FileName parameter.
Through a direct connection to the database.
Use parameter sets that include –DatabaseServer and –DatabaseName when the Microsoft Dynamics NAV Server instance is stopped or not available. For example, if you want to import an updated application into a database, you stop the service so that users cannot access the database.
You must have access to write to the location that is specified by the –FileName parameter.
The following table describes the Windows PowerShell cmdlets that are modified in Microsoft Dynamics NAV 2013 R2 Cumulative Update 8.
Gets a list of the Microsoft Dynamics NAV companies in the specified tenant database or exported Microsoft Dynamics NAV data file.
The cmdlet has been updated to be able to get information from a Microsoft Dynamics NAV data file.
However, the Help for the Export-NAVData and Import-NAVData Windows PowerShell cmdlets does not show the correct syntax when you run a command such as the following:.
PS C:\WINDOWS\system32> Get-Help Export-NAVData
Refer to the following syntax for the Export-NAVData cmdlet:
Refer to the following syntax for the Import-NAVData cmdlet:
You can find more information about this functionality, and the new or changed objects, in the following documents on the W1 version of the Microsoft Dynamics NAV 2013 R2 CU8 download media:
In subsequent cumulative updates, the documents will be available in the country-specific downloads as well.
I'm aware that this is mentioned in the pdf, but for partners who need to offer support for all versions which are now changing every month there is a severe drawback to this fbk replacement:
With the fbk files, you could create a file with company field data only, and import that into a database with addon objects (identical base) where the modifications include some extra fields in standard tables. That is essential for a swift creation of a standardized environment in which posting behavior and other alleged issues may be reproduced.
Now that is not possible anymore because an error message pops up that the database schema differs. So now you need to create a separate database with standard objects first, then import the company data, and afterwards the addon objects. Then you have export the Cronus data from this temporary database and reimport that into the database where you really need it. A big waste of time.
Thank you for your feedback.
For this scenario you can create the empty database, and then import everything using the NAV Administration Shell. Something like:
PS C:\> Import-NAVData –FileName your.navdata -DatabaseName db -IncludeApplication -IncludeApplicationData -IncludeGlobalData -CompanyName yourcompany
it's good to see some essential functionality back (although, somehow... changed ;). If it's a feature-complete replacement of the .fbk... we'll see. I'm afraid Kai is right, you import a "standard" company into your *existing* development database (with slightly different objects, and additional fields in tables), change to this company and do the tests. And this apparently doesn't work... why? I see no reason for this.
with best regards
And new C/AL functions :
no documentation for these so I don't know the syntax...we can guess it :)
Just check the new Pages : 9900, 9901
and the documentation from W1 DVD
Okay, I've tried this ... not impressed.
Mark Brummel released an SQL script generator to allow this level of functionality within days of the problem going public. As people said at the time this solves one or two minor use-cases but it does NOT provide anything like the level of functionality available using the FBK file.
It does not make the task of updating a test database easier; it's just as easy and a lot quicker to use the SQL backup and re-add the modified objects on top.
It does not allow base demonstration data to be loaded into a database with modified objects.
It does not allow merging data from different locations, such as Object Manager C/AL history and real user data.
Unfortunatly, I can't say I'm surprised. But I am still disappointed...
Sigh. Looks like I'll have to improve my 'hack and slash' script so other people can use it. Such a waste of time.
I have try the new functionally and it seems not to be work.
Here my Powershell statements:
Export-NAVData -ServerInstance DynamicsNAV71 -FileName 'C:\mydasi.navdata' -Description 'Das ist meine Beschreibung' -IncludeApplication -IncludeApplicationData -IncludeGlobalData -AllCompanies -Force
Create a Database called Empty from SQL Mgt. Studio
Import-NAVData -DatabaseServer PC-JUERGEN -DatabaseName 'Empty' -IncludeApplication -IncludeApplicationData -IncludeGlobalData -AllCompanies -filename 'C:\mydasi.navdata'
Setting the correct Collation with Development Client
Starting Service Tier
Connecting with RTC, the following Error occours in EventLog (Part of the Message):
Invalid object name 'Empty.dbo.$ndo$cachesync'
This Table is in the original DB but not in the restored DB
The $ndo$cachesync table is not created when data is imported rather this is a table that the server creates “on the fly”. Guess is that the problem here is that the NST does not have necessary permissions on the new database that the data was imported into. The NST account needs to have the db_owner permission on that database otherwise it will not be able to access the data. The event log should reveal this.
Can you confirm that?
I tried it and had the same problem with $ndo$cachesync not being created. Even if the user running the service is set as db_owner.
My solution was to create that table manually from SQL.
I have checked my restore again.
The ServiceTier User Account are DBOwner (This user is sysadmin on SQL).
When I create the Table $ndo$cachesync manually the RTC seems to work fine.
Same as Rafael says.
Regarding import into a new empty application database.
We have found two problems in conjunction with this:
1. The mentioned problem regarding $ndo$cachesync not being created. Workaround is to create it manually as already mentioned.
2. The collation used by NAV is set incorrectly. Workaround is to set it using C/Side before importing data or to set it manually using SQL Server management studio when the new database is created.
We are working on a hotfix for both of these issues.
These updates have become an embarrassment. Issuing major database feature changes every month that are overcomplicated and buggy make it look like Microsoft does not care about the Customer and is more interested in making revenue through skyrocketing support costs than in improving the "User Experience". And it makes the implementers look stupid when they aren't up with this weeks new features and then, in addition to that, they can't make them work and have to hunt for the documentation. At this rate it will soon be so costly to upgrade that people will elect to re-implement, but with some other product that promises to make things easier, like this product used to do.
I don't understand the function in the Client, it doesn't works correct. IF I make an Export of one Company in my testsystem to read in in a customer System. The System gives an error message incorrect scheme, Import not possible. The structures of both database are the same. To use the powershell remebers me on functions of MS DOS, but we have the year 2014 not 1990. To get and type in all the different Parameters, you must be Administrator on customer System, use a big waste of time, this can't be a modern Technology!
In older versions of NAV, when starting a backup with finsql.exe NAV client, the whole database was automatically locked for consistency reasons, preventing other users from writing any data during the backup. I suppose, this is also true for this new data export functionality, isn't it?
Let me one question for all of you who tested the solution successully.
Is it mandatory to create a multitenant database structure to use this tool?
We've checked the solution between 2 different SQL databases (both have the same objects) and we've received following message error: "Cannot import the data because the database schema in the database is different from the schema for the data that you want to import".
I thought could be a problem from SQL, so I've tried the same action on the same SQL database (exporting data, renaming the company and trying to import the company exported). I received the same message error.
So I want to know if it's mandatory to create a multitenant structure between both databases to apply this process successfully.
Thank you for your help in advance.