G/L Compression

Business Central/NAV User Forum
1

Hi All,

Hope someone can help with this problem,

We’ve been trying to run the G/L compression in Navision,

First time we tried we selected a range og G/L codes and a date range of six months and it did not work.

Tried selecting all G/L codes for a period of one day and it did not work.

Anyone got any ideas on how to do this correctly?

Thanks

Paul.

2

what do you mean by “don’t work”?

3

Hi Thanks for the reply.

I cannot acces this forum from work.

I have a screen shot of the error message at work I will note the detail and let you know.

The consultant we use has not been able to identify the problem.

He thinks it might have something to do with a transaction description that exceeds the character limit for the field.

I questioned how it would be possible for a user to make an entry which exceeds a limit.

He explained that it may be an entry made by the Biztalk app. that our company uses.

I will send you a step guide of what we have done in our attempts.

If you were running G/L compression (which I am assuming has not been modified) what would the steps be?

Thanks again for your interest, I hope you can point me in the right direction.

Cheers

Paul

4

There are few threads about “date compression” here and on mibuso.com (which is temporarly unavailible for a few days).
There is not much to say about compression and almost everything you may find in help file.

compression batch job has a problem if there’s a lot of modifications on ledger tables and if you have “character limit” errors, most probably that you do have some modifications…

5

Paul,

why are you compressing? Its something that you really should never do with out a very good reason. It will only cause you problems down the line.

6

Hi,

Our consultant seems to have solved the issue. he said the error was being caused by something to do with the progress bars on the dialogue box which appears when G/ L compression is running,

Have you ever heard of anything like this?

We kicked off a test of a months worth of transactions on a test database this morning, it was still running when I left, will look to see what has happened in the morning.

Thanks for your help.

7

I believe the reason we are doing this is due to the size of the database, backups and report running are taking longer and I know that IT are planning some mods which I guess will put more running problems on the database,

Do you have any other methods to improve system performance?

Thanks for your interest and comments

8

There are many ways to improve system performance, but Date Compression is really not one of them. The amount of space you save is too trivial for it to speed up your system. On the other hand, it can cause so much damage to your database that nearly everyone that compresses data regrets it a year later. Keep in mind that it will probably take a year before you realize how much damage has been done. And then when you realize that the system is not any faster, you will feel even worse. The compression routines are a left over from a time when you had to pay for Navision database, and thus it was very expensive to have large databases.

If your system is slow, then there are many other things you can do to fix it. In fact I just got back from a client in exactly the same scenario, their partner told them to compress data to speed up the system, the system did not speed up, and they have a mess created from the compression.

Please think of compression as the absolute last resort after you have tried everything else possible.

PS I have been fixing performance issue in Navision for about 12 years now, and never once has Date Compression helped. I had one case where compression looked like it would help, (it was a POS solution), and in the end we realized that the POS was posting raw data, and then they were compressing. The proper solution was to fix the error in the POS system.

Anyway, the key here, is that if you eventually did decide to compress, then you need to do some very exhaustive testing, make sure all your accounting reports and accounts schedules run correctly with and without dimensions, make 200% certain that you are still able to close your financial year. And absolutely make certain that you do specific performance testing before and after to make certain that you do get a significant performance gain. Please don’t compress just because “well we think it will help”.

9

David, could you be more specific on What kind of problems could be after date compression, exactly?

Except of loosing analyse data, which is normal after deleting details, these could happend (though I don’t claim it will):

  • Inconsistency of data? (Data compression batch doesn’t work properly?)
  • Logical inconsistency? (GL entries could be compressed wihtout compressing of other ledgers)
  • Operational problems? (Suddenly, customer apply of entries doesn’t work, errors raising, cannot close year cause of strange errors => data compression batch doesn’t work properly?)
  • Reporting problems? (Some of reports has calculations based on full navision data history which could be messed with data compression and it’s not working properly any more => data compression is ok but reports and batches aren’t?)
  • Any other?

In brackets are my comments on possible problems with data compression without too much expirience in that specific procedure. I saw on few places that you heavily disagree with use of data compression batch but, as arguments, you used general terms as “messed up database, benefit on real data loss was not too big”, etc… I would like to know, why, really do you think that it is not ok to use it? Did you have some specific negative expirences and which kind off were they?

(to clarify, I’m not arguing, just want to know a little bit more on specific topic).

10

Basically if you run Navision out of the box, with no modifications, and you have a very simple system, i.e. no warehouse, no complex application of payments, no manufacturing, no returns no inventory costing issues, then you can possibly run it without problems. But I think that any company with enough transactions to be considering compression, would not be in this scenario. Maybe a company that is just G/L. AP AR and they consolidate millions of entries.

In the real world, you need to consider what the benefits of compression are? Is it to save some disk space? If so how much will you save? You might reduce your database by 10% overall, isn’t it just cheaper to go out and buy a couple of new hard disks.

As to problems, YES to all the issues you mentioned, though buggs in the routine I only saw on databases converted from 2.60 to 3.01 or 3.10, they just didn’t handle the Value and detail ledgers correctly. Definitely though I have seen all the issues you mention.

Basically if your company seriously needs compression, then you need to look at the source, and look at how compression suits your business model. For a starting point, any compression needs to work in two dimensions (currently it works only in one- date) it needs to compress dates across documents, so that you are not left with partial documents that really can not be used. So Step one should be to scan and delete all invoices and shipments as sets, check all entries to make sure everything is resolved, including making sure that there is not some applied adjustment extending into an open accounting period, and then mark all the ledger entries as compressible. Once the data is scanned at document level, it cna then be compressed date wise. (Of course this logic needs to extend to dimensions). Also compression should be a part of the initial design of the system, so that as more system changes are made, the developers and designers make sure that what they do will be compressible later.

Secondly most companies never anticipate in advance that they will compress data later, but there are some times that its obvious, for example POS and retail. In these cases, it really is not necessary to have every item ledger entry and every customer ledger entry in the system, especially if the invoice is paid at posting time. But rather than compress, the correct solution is to post the transactions to a buffer/holding journal, and only post summary figures say daily or weekly.

In summary, I have seen a number of cases where Compression caused significant problems, and I am yet to see a case where compression gave any benefit at all.

if anyone has run compression on all their entries, it worked fine, they never regretted it AND it gave a significant performance improvement, I would like to hear about it. But I am not too interested in cases where it saved them spending a few hundred bucks on a new hard drive.

11

Ok, thnx on brief answer.

Btw. not our company but our client (we are NSC) and their main reason for compression is to speed up some of the calculations that are processing a lot of data in previous years. Although they aren’t POS/Retails system, they do have a hell of a lot of big invoices.

Probably would be best to optimize more the system or even to adapt/modify those calculations.

My worst fear with compression routines are some hidden errors in routine itself that could make a lot of headache…

12

Hi David,

Just wanted to thank you for your posts to my thread. The information you have provided can now ensure that we are making an informed decision about this.

the information both you and other members have posted will i think, put a stop to the view that compression may work for our company.

We done a test last week and the space saved was not very significant and from my point being an enduser on the G/L, the loss of detail would cause a lot of problems.

Thanks again for your input, I will let you know the out come.

Cheers

Paul

13

Hi

thanks for your input to my original thread, the more info i have on this subject the better to enable us to make the right decision

thanks again

PAul

14

Paul you are very welcome. we are here to help. I have marked the topic as resolved, you can give it a star rating if it helped you.