Archiving Navision Financials Data

I am investigation on what are the different alternative for archiving Navision Financials data (The reason being is that I have a customer having a huge database and would like to reduce it’s size, there seems to be performance issues…) One of the solution which comes to mind is : At the end of each fiscal year is to do the following : 1/ Do a full backup of the company data (ie : cronus2000.fbk) 2/ restore the cronus 2000.fbk in into a new database containing the application object 3/ compress the ledger entries in the live database So basically in your archives folder you will end up with DB archives for all your fiscal years. ie: cronus1998.fdb, cronus1998.fdb, cronus 1999.fdb, cronus2000.fdb All that to ask : 1/ What are the other alternatives (if any?) for archiving data 2/ What are the replication tool available beside the one at ? Edited by - Tarek Demiati on 2001 Aug 02 07:41:11

Hi Tarek, I have not thought about archiving data that much. But be aware, the compression by date function is not working very well. Anyway, the problem is still, how “deep” schould the date compression be. Reducing to one posting per day makes no sense. You should reduce it to at least one posting per month. And if you want to keep all the department and project informations, you still have a lot of bookings into the accounts. As well, with one posting per month, you are still able to compare the data with the last year results. A lot of space, I think much more than the ledger entries, is used by the posted delivery notes and the posted invoices (header and lines). So, if you do not need this informations into the database, you can delete them when they are printed once. Please use this obtion together with your “Yearly Backup Database”. Replication is exactly doing what the name says, it replicates a database (or parts of it); if you want, in both directions. The only way the replicator would help you in this case, is to install the replicator for your backup solution. I my opinion, replicator is to exspensive only for using it once a year. In fact: - delete what is not in need (posted headres and lines) (think of the posted credit notes etc. as well) - date compression down to one booking per month. If you do not need the comparison to the last year, down to one booking per year. Best regards Walter

Yes, be sure to check the compress functions before you do it. Some years ago I compressed the Item Ledger Entries for a customer “by to the book”, but it still had some “side effects”. A few weeks after when the customer executed the “Adjust Cost” Batch process it failed, for some reanson the batchjob was searching for the compressed and deleted entries… So atleast in those days it was not reliable. I had no time to look into it more than just fix it at that time, and not really felt like bringing it up again…:wink: I guess it is the Item Ledger entires in your case as well. Another thing can be if your concern is it will mess up the sales staistics, don’t compress the sales entries, just the rest. Atleast you get rid of some transactions. About the posted documents, I don’t belive deleting them is gona improve performace much since they not are accessed much in the operational flow by the system after posting. Only shipments and reciepts that i can think of in case you use Combine shipments or Get reciepts functions. -“By new HW and move to S Q L, We only charge a few C/SHELL” :slight_smile:

Tarek, We recently did an archive and compress for a client reducing their primary databse from 6GB to about 2.5GB. All the compressions seemed to have worked just fine for us. We compressed on a quarterly basis because that seemed to be the option that gave us the fastest run time for the compression processing. (We were doing the compression and archiving as part of a major upgrade and speed of getting the job done was critical.) We compressed the Item Ledger, General Ledger, Customer Ledger, and Vendor Ledger. We also deleted data more than two years old from various history files (Posted Invoices, Posted Shipments, etc.) We’ve been back in production for about three months and haven’t seen any negative effects from our compressions. Dave Studebaker das@libertyforever

Try to look into LaserNet Archive. ! With LaserNet Archive you can store all the print that is generated in LaserNet Print or in general, whether it is sent by mail or fax. LaserNet Archive will store the full print including the adjustments that have been made during the print of the document. On each type of report, that has to be stored, a number of search keys are set up to be used in connection with the search for a specific document. The search keys are selected based on the information of the data stream and are stored with the document so that the users afterwards can make a search for various criterias such as customer number, invoice number, etc. As optional features, LaserNet may be supplied with a.o. web access and scanning.