Problem with importing Company backup trough powershell

So this is my situation - I have two databases - Originall database (Lets call it Database A) and temp database (we will call it Temp). Temp is Demo database (9-0) that came with NAV 2016 installation. These two databases are same build.

So what I did.

1.) Export all objects from A

2.) Export one company from A (this is new company with only setup, no other data)

3.) Imported objects from A to Temp and compiled them

4.) Import company from A to Temp with powershell (Import-NAVData).

After this i get error that I don’t have enough space. So I tried to investigate, ant in my sql server databse limit is 10GB, and I have set the autogrowth setting to 300MB, unlimited.

So I don’t get it why a company backup file that is 600MB large, cause database to grow beyond 10GB ?? Is there any normal explanation ??

Hi Junior,

Did you find out where the error originated? What was the exact error message?

And was it from the SQL database? Did event log leave a trace?

Error was - Import-NAVData : Could not allocate a new page for database ‘Demo Database NAV (9-0)’ because of insufficient disk space in filegroup ‘PRIMARY’. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

Error ocured because database reach 10 GB size that was SQL server limit. It is not logical that only one company 600MB size during import gives dabase larger then 10GB …

Hello Junior

The short answer is yes, the database can easily grow to more than 10gb during the upgrade - Remember that if your backup takes around 600mb then the actual database size (with all the sortingkeys and flowfields) easily can be multiplied with 5-6 times meaning more than 3 gig - All data is stored at least twice during the upgrade AND the Transaction log grows to an insane size.

So upgrading is not done with with 10gig limitation database sorry.

(When finished you can do a SQL backup and the database will usually take up 3 times the size of an NAV2009 base when its converted to +NAV2013.

PS Dont set your autogrowth to 300mb - let be at the default value which is autogrowth 10%

Regards

Palle

PS. Be aware of that you might have to redo the upgrade again, depending on how far the upgrade went, you might have to start all over with the import.

I tried with default settings to, but outcome was the same.

One more thing

Also take a look here:

https://blogs.msdn.microsoft.com/nav/2015/02/23/upgrading-from-microsoft-dynamics-nav-2009-r2-or-microsoft-dynamics-nav-2009-sp1-to-microsoft-dynamics-nav-2015/

Read the user comments!

One of the main reasons is that when you upgrade, the database is converted to Unicode which by default doubles the size of a varchar field.

Yes… the autogrowth is a matter of HDD-space reservation. The 10% gives the best performance of the database.

Sorry but I don’t get how this is connected I am not doing a upgrade, this is two databases from same version and build.

The client that you are going to run is it a NAV 2009 or a NAV 2016? and what update?

Palle it’s late. Nobody was talking about NAV 2009, he wrote 9.0 = NAV 2016. [emoticon:c4563cd7d5574777a71c318021cbbcc8] [emoticon:591b528a84b3405eb929950ed66f384e]

And as I understand, then you’re not importing a SQL backup, but a NavData file. The NAV file is really RAW data, so I’m more interested in know how big the original database was.

Ahh yes sorry my bad its to late :slight_smile:

The main problem here is the NAVdata format - it really has issues so its a matter of what version (Buildno) of NAV 2016 that is being used.

Secondly one must be aware of that the 600mb data is the RAW data and the actual database size is way bigger (6-8 times bigger) because not only of the sorting keys space but also the creation of the transaction log.

Besides it was never the intention of NAVdata-backups that it should be used with so big databases.

Yes that’s right.