Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Everyone once in a while, we will get a support call from a customer about archiving their historical data.
Dynamics NAV (formerly Navision) has been in the US since 1996 and for customers that were first to adopt Dynamics NAV, they have kept those data with them through the years.
Some will argue that with the cost of storage in decline, why is it necessary to archive old data. While I tend to agree with that statement, but trying to manage a 700 GB database backup, if nothing else, very time consuming.
There are a couple of ways to “shrink” the size of your database by eliminating the data within Dynamics NAV.
Date Compression Dynamics NAV
The date compression processes will consolidate multiple entries in the table in question into one entry.
The problem with date compression process is that it takes a loooong time to run. It takes so long to run that we usually just stop the process. The design of the Date Compression process seem to want companies to run it periodically when they start using NAV instead of running it when you’re database is 700GB. This is never the case.
Most Dynamics NAV consultants out there will never recommend their clients to use Date Compression (me included). One of the main reasons is because in the prior versions of Navision caused data problems when you did date compression when you try to upgrade.
There are data in the database that one can consider as low priority value. You’re keeping the historical data, but the historical data is more “nice to have” instead of regulatory compliance or critical to running the business. These tables include, but are not limited to:
This is not to say you should delete all of the data, but you can certainly delete those data not required by the tax or audit authorities.
This is the nuclear option. Basically, start fresh in a new Dynamics NAV database with only your setup data, master data, and opening balances. This option is popular with companies that have been using Dynamics NAV for a long time. It gives an opportunity to eliminate a lot of bad data, in addition, to modifications that are no longer needed.
The historical information is basically kept at the old database environment. If an old data is needed, the user basically goes to the old NAV database to retrieve the information.
But re-implementation is really overkill to specifically address the database size issue.
With the performance and capacity of storage ever increasing and the cost of storage ever declining, these types of question does not come up as often. I suspect as time progresses, these questions will come up once in a very long while.
I typically would recommend companies remove the data that adds little or no value first before attempting to do anything drastic. Usually holding those data takes a ton of storage in the Dynamics NAV database.
There was a company I visited that had 10 GB worth of Change Log entries. Worst is that the customer didn’t even know what the change log is…
Business Applications communities