Data Compression & Deletion In Navision 3.10

senna

Has anyone got any hints or tips on the best use of the data compression and deletion tools in Nav 3.10??

I am currently working with a customer who has had this problem previously, during the first attempts a while back we found that that there was some items with a discrepancy between the inventory and no. of stock units and some of these items were found to have problems after the stock entries compression. We also found that the item ledger entries compression did not compress at all. Is there generally a best practice way around achieving this?

I am also looking at deleting some records where it is not set as a transaction type of entry. The customer is looking to only have 2 years worth of 'live' data so are looking at specific areas for deletion consisting of Production BOMS, Versions which have been set to closed, Finished Quantity Orders, Finished Production Orders and invoiced shipments and receipts in the required date range as these have been effectively turned into invoices.

Any hints/tips or guidance greatly appreciated.

senna

Shame ive not had any replies here.... was it something i said

Seriously though if any of you Navision experts have any general advice on data deletion and compression methods, i'd love to hear what you got to say...

David_Singleton

There are a lot of issues with Date compression, these issues continue in NAvision for at least 15 years, so nothing new.

The first thing is that the routine by their nature do not handle any mods made to the ledgers. So you need to carefully address these issues. More importantly is that 3.10 was very much a problematic version, so if you are using manufacturing, especially with Lot or Serial Numbers, then expect issues. If you upgraded from 3.01 to 3.10 then expect those issue to be multiplied 10 times.

Bascially I allways advice users, that if you have any substantial level of mods, or if you have upgraded, then you really need a good analyst to take a look at how compression works, and see if it truely suits your requirements.

I know there is a concept that reducing database size will make the system faster, but really it wont make as big a change as you may expect. (That is using the standard routines).

As to your comment

I am also looking at deleting some records where it is not set as a transaction type of entry.

I have no idea what that means, so please clarify.

senna

Thanks for your reply David.

I sense an element of caution in your response and with all the issues you mention and sadly it doesn't surprise me.

Unfortunately the database in question does have a number of modifications so I do think I am going to run into complications with some of the data, not mentioning the other problems you kindly have pointed out with version 3.10

What I mean't by " deleting some records where it is not set as a transaction entry" was specific Items such as Production Boms / Versions which have been set to closed, Finished Quality Orders, Finished Production Orders, and even possibility invoiced shipments and receipts in the required date range as these have effectively been turned into invoices.

Sorry for the lack of clarity and thanks again for the information so far

David_Singleton

senna wrote:

Thanks for your reply David.

I sense an element of caution in your response and with all the issues you mention and sadly it doesn't surprise me.

Unfortunately the database in question does have a number of modifications so I do think I am going to run into complications with some of the data, not mentioning the other problems you kindly have pointed out with version 3.10

You are welcome.

Just to clarify, that the Date Comprssion isssue, is not so much an issue of Navision, more of the business model of the customer. If you look at the routine, you will see that it only looks att he core Item Ledger (Entry, Value and Appplication) tables, and Dimensions. It does not look at thinks such as Physical inventory, BOMs, manufacturing Invoicing, Orders etc. So if your busniness model requires links between these tables, then Date Compression could easily delete information, that whilst not critical to Navision's structure, is important to you business.

senna wrote:

What I mean't by " deleting some records where it is not set as a transaction entry" was specific Items such as Production Boms / Versions which have been set to closed, Finished Quality Orders, Finished Production Orders, and even possibility invoiced shipments and receipts in the required date range as these have effectively been turned into invoices.

Sorry for the lack of clarity and thanks again for the information so far

Yes that is the issue, that basically the Date Compression does not take into account the related data structure.

On a further note, you may also find that the compression routine keeps a lot of data that your business does not need, at the saem time as deleteing things that are needed. Thus I always recommend that the routine is used as a base, and that you build your own compression to work with your business.

Again this is NOT a bug or a problem with Navision, its just that the routines do not suit most users.

senna

These queries originate from a customer i'm currently dealing with on Nav 3.10 who have a fairly big database (35GB and expanding...) who are having continuous performance issues is various parts of the database.
They are heavily modified in the Production/Planning aspect of Navision so hence my reluctance to attempt any of the standard compression tools.

Thinking alternatively here, are there any other recommendations to improve performance?? I have already looked at hardware (customer using 3gb processor) but this doesn't seem to have improved anything and they are very keen to resolve these ongoing issues.

Are there any benefits to performance / hardware capability if this customer were to upgrade to V4.00 or V5.00 at a later point?

Again, any advice is appreciated

David_Singleton

Add more Hard disks, you can never have enough hard disks.

senna

Thanks David.... by operating from more hard disks is this guaranteed to improve performance?

Apologies in advance for my obvious questions.....

David_Singleton

In virtually every case, more disks will make Navision faster.