Item Ledger Compression in 5.1

slowhandfan

We are upgrading many of our customers to 5.1 and have noticed that Report 798 (Date Compress Item Ledger) is missing. We have customers that generate millions of Item and Value Entry records through sales transactions and despite it's problems in earlier versions we have used it successfully to compress to monthly levels when needed. Anyone know where it went and why?

I suppose I could copy 798 from a 4.3 version to a 50000 range but that would require extensive testing, especially with cost considerations.

ara3n

I've looked at 2009 and 2009 sp1 and it looks like it's not coming back.

bbrown

ara3n wrote:

I've looked at 2009 and 2009 sp1 and it looks like it's not coming back.

Yippee!!!!! =D> =D> =D> =D>

kine

I guess that it is because now MS SQL is default solution for the NAV and it can handle BIG tables if set correctly.

jannestig

Read the release statement it states big and bold its gone for good.

David_Singleton

bbrown wrote:

ara3n wrote:

I've looked at 2009 and 2009 sp1 and it looks like it's not coming back.

Yippee!!!!! =D> =D> =D> =D>

:-k not sure if I feel the same as you. That routine in most cases destroys databases, and my job is fixing databases, so yeah it's great in many ways, but does it mean less work for me in the future?

ara3n

I spent last month on a client database fixing ILE, value entry, Item application quantity fields. It wasn't fun.

A consultant/dev had run a processing report and had zeroed out qty in ILE.
The application were screwed up. It was a lot of work to make sure all the qty, rem qty and item application qty and entries were created correctly.

db

David Singleton wrote:

bbrown wrote:

ara3n wrote:

I've looked at 2009 and 2009 sp1 and it looks like it's not coming back.

Yippee!!!!! =D> =D> =D> =D>

:-k not sure if I feel the same as you. That routine in most cases destroys databases, and my job is fixing databases, so yeah it's great in many ways, but does it mean less work for me in the future?

Now compresion become secret magic tool and will worth only more O:)

Alex_Chow

db wrote:

Now compresion become secret magic tool and will worth only more O:)

The only compression I would use are anything other than inventory related.

G/L compression is good and customer/vendor compression is good. Just stay away from inventory.

db

Alex Chow wrote:

db wrote:

Now compresion become secret magic tool and will worth only more O:)

The only compression I would use are anything other than inventory related.

G/L compression is good and customer/vendor compression is good. Just stay away from inventory.

Sure, but only for original compression routine. Inventory tables are most painfull in all db and compression of it gives best results, but inprovement of code is essential.

Alex_Chow

db wrote:

but inprovement of code is essential.

Or in this case, completely eliminating it.

bbrown

I don't know how many times I hear data compression/deletion being recommended as a first-pass solution to resolve performance issues.

slowhandfan

jannestig wrote:

Read the release statement it states big and bold its gone for good.

I can't find the release statement anywhere. Is there any reason why it went away? 3.6 was the only version where it was really trash. We have had success with it at 3.7 and 4.3.

We have a few customers that can accumulate 100GB of data per year with 70% of that being Item Ledger and Value Entry.

bbrown

slowhandfan wrote:

jannestig wrote:

Read the release statement it states big and bold its gone for good.

I can't find the release statement anywhere. Is there any reason why it went away? 3.6 was the only version where it was really trash. We have had success with it at 3.7 and 4.3.

We have a few customers that can accumulate 100GB of data per year with 70% of that being Item Ledger and Value Entry.

Microsoft probably got tired of the support calls when it doesn't work right. ](*,)