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.